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

From Markus Wanner
Subject Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format
Date
Msg-id 50F3C9F4.6050200@bluegap.ch
Whole thread Raw
In response to Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format  (Hannu Krosing <hannu@2ndQuadrant.com>)
List pgsql-hackers
On 01/13/2013 09:04 PM, Hannu Krosing wrote:
> 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"

Intel being little endian seems like a bad choice to me, given that
send/recv kind of implies network byte ordering. I'd rather not tie this
to any particular processor architecture at all (at least not solely on
the ground that it's the most common one at the time).

I have no strong opinion on "sameness" of NULLs and could also imagine
that to throw some kind of invalid operation error. Based on the ground
that neither is a value and it's unclear what send() method to use at all.

FWIW, trying to determine the length of a sent NULL gives an interesting
result that I don't currently understand.

> psql (9.2.2)
> Type "help" for help.
> 
> postgres=# SELECT length(int4send(NULL));
>  length 
> --------
>        
> (1 row)
> 
> postgres=# SELECT length(float4send(NULL));
>  length 
> --------
>        
> (1 row)
> 
> postgres=# SELECT length(textsend(NULL));
>  length 
> --------
>        
> (1 row)
>
> postgres=# SELECT length(textsend(NULL) || '\000'::bytea);
>  length 
> --------
>        
> (1 row)


Regards

Markus Wanner



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format
Next
From: Dean Rasheed
Date:
Subject: Thinking about WITH CHECK OPTION for views