Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format
От | Hannu Krosing |
---|---|
Тема | Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format |
Дата | |
Msg-id | 50F3134F.5090109@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format (Markus Wanner <markus@bluegap.ch>) |
Ответы |
Re: Re: logical changeset generation v3 - comparison to
Postgres-R change set format
|
Список | pgsql-hackers |
On 01/13/2013 06:02 PM, Markus Wanner wrote: > On 01/13/2013 12:30 PM, Hannu Krosing wrote: >> On 01/13/2013 10:49 AM, Hannu Krosing wrote: >>> Does this hint that postgreSQL also needs an sameness operator >>> ( "is" or "===" in same languages). >> How do people feel about adding a real sameness operator ? > We'd need to define what "sameness" means. If this goes toward "exact > match in binary representation", this gets a thumbs-up from me. > > As a first step in that direction, I'd see adjusting send() and recv() > functions to use a portable binary format. A "sameness" operator could > then be implemented by simply comparing two value's send() outputs. This seems like a good definition of "sameness" to me - if binary images are bitwise same, then the values are the same. And if both are fields of the same type and NULLs then these are also "same" And defining a cross-platform binary format also a good direction of movement in implementing this. I'd just start with what send() and recv() on each type produces now using GCC on 64bit Intel and move towards adjusting others to match. For a period anything else would still be allowed, but be "non-standard" I have no strong opinion on typed NULLs, though I'd like them to also be "the same" for a sake of simplicity. As this would be non-standard anyway, I'd make a row of all nulls NOT "be the same" as NULL This would be much easier to explain than losing the "IS NULL"-ness at nesting level 3 ;) Hannu > > Regards > > Markus Wanner > >
В списке pgsql-hackers по дате отправления: