Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format
Date
Msg-id 50F3134F.5090109@2ndQuadrant.com
Whole thread Raw
In response to Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format  (Markus Wanner <markus@bluegap.ch>)
Responses Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Next
From: Dimitri Fontaine
Date:
Subject: Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format