From: Konstantin Osipov <kostja@tarantool.org> To: tarantool-patches@freelists.org Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Subject: [tarantool-patches] Re: [PATCH 2/3] Add surrogate ID for BINARY collation Date: Thu, 1 Nov 2018 18:39:15 +0300 [thread overview] Message-ID: <20181101153915.GL30032@chai> (raw) In-Reply-To: <2B8A8EDD-2479-4C1F-9FF3-E17B16DFB0AE@tarantool.org> * n.pettik <korablev@tarantool.org> [18/11/01 16:11]: > >> I guess, because > >> > >> 1) It is not real collation and is not presented in > >> _collation. So for a user it would be strange to see > >> a gap between 2 and 4 in _collation, which can not be > >> set. > > > > Let's insert it there. > > So, you insist on id == 3, right? Again, if user process select > rom _collation space, one won’t see entry with id == 3. > On the other hand, if user attempts at inserting id == 3, > one will get an error. No, I don't insist yet. Why not insert a special row in there? > >> is consistent to has its ID near COLL_NONE, in a "special > >> range" of collation identifiers. > > > > Uhm, AFAIU we have two binary collations. One is "collation is not > > set" and another is "collation binary". Which one did you mean > > now? > > FIrst one is not collation at all. It is rather “absence” of any collation. > The second one is sort of “surrogate” and in terms of functionality > means the same. However, its id will be stored in space format in > order to indicate that BINARY collation should be forced during > comparisons. I think we could use internal ids to reference both cases. For these both ids we could have surrogate rows in _coll system space, they won't harm. This will make things easier in the future. This is going to be the same mess as with NO ACTION and DEFAULT, which are mostly the same, but not quite, so we'd better prepare. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov
next prev parent reply other threads:[~2018-11-01 15:39 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-25 11:00 [tarantool-patches] [PATCH 0/3] Change collation compatibility rules according to ANSI SQL Nikita Pettik 2018-10-25 11:00 ` [tarantool-patches] [PATCH 1/3] sql: do not add explicit <COLLATE "BINARY"> clause Nikita Pettik 2018-10-25 11:00 ` [tarantool-patches] [PATCH 2/3] Add surrogate ID for BINARY collation Nikita Pettik 2018-10-31 12:34 ` [tarantool-patches] " Vladislav Shpilevoy 2018-10-31 15:47 ` n.pettik 2018-11-01 11:37 ` Konstantin Osipov 2018-11-01 12:22 ` Vladislav Shpilevoy 2018-11-01 12:58 ` Konstantin Osipov 2018-11-01 13:08 ` n.pettik 2018-11-01 15:39 ` Konstantin Osipov [this message] [not found] ` <95CB17D5-E3ED-4B05-A289-983E2FD0DE37@gmail.com> 2018-11-01 17:45 ` n.pettik 2018-11-01 20:00 ` Konstantin Osipov 2018-11-01 20:06 ` Konstantin Osipov 2018-11-01 20:20 ` n.pettik 2018-10-25 11:00 ` [tarantool-patches] [PATCH 3/3] sql: change collation compatibility rules Nikita Pettik 2018-10-31 12:34 ` [tarantool-patches] " Vladislav Shpilevoy 2018-11-12 23:46 ` n.pettik
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181101153915.GL30032@chai \ --to=kostja@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=v.shpilevoy@tarantool.org \ --subject='[tarantool-patches] Re: [PATCH 2/3] Add surrogate ID for BINARY collation' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox