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

In response to

• Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format at 2013-01-13 20:04:31 from Hannu Krosing

pgsql-hackers by date

Next:	From: Dean Rasheed	Date: 2013-01-14 09:29:56
	Subject: Thinking about WITH CHECK OPTION for views
Previous:	From: Hannu Krosing	Date: 2013-01-14 08:51:01
	Subject: Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format