Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format
От | Markus Wanner |
---|---|
Тема | Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format |
Дата | |
Msg-id | 50F3C9F4.6050200@bluegap.ch обсуждение исходный текст |
Ответ на | Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format (Hannu Krosing <hannu@2ndQuadrant.com>) |
Список | 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 по дате отправления: