Skip site navigation (1) Skip section navigation (2)

Re: BUG #5748: Invalid oidvector data during binary recv

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Yeb Havinga <yebhavinga(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5748: Invalid oidvector data during binary recv
Date: 2010-11-15 16:51:46
Message-ID: 16032.1289839906@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
I wrote:
> Yeb Havinga <yebhavinga(at)gmail(dot)com> writes:
>> Binary send and recv of the value at hand would change it into a 0-D vector.

> The reason for that is that in general we don't make a distinction
> between zero-size arrays of different dimensions.

Actually, after consuming a bit more caffeine, I see what Yeb is on about.
Even though the system in general doesn't make much of a distinction
between zero-element arrays of different dimensionalities, there *are*
functions that can distinguish --- array_ndims() being the most obvious
one.  Shouldn't we ensure that binary dump and reload of an array value
doesn't change the value in any SQL-observable way?  If so, I think his
patch is correct, even though it's changing more than just the
originally-complained-of behavior.

While I'm looking at this ... why is it that array_ndims returns NULL
and not 0 for a zero-dimensional array?  0-D arrays might have been
unsupported at one time, but they're certainly considered valid now.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Greg StarkDate: 2010-11-15 17:11:08
Subject: Re: BUG #5748: Invalid oidvector data during binary recv
Previous:From: Tom LaneDate: 2010-11-15 15:22:07
Subject: Re: BUG #5748: Invalid oidvector data during binary recv

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group