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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Yeb Havinga <yebhavinga(at)gmail(dot)com>, 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 17:24:26
Message-ID: 16687.1289841866@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Is this the same question as split() on enmpty strings? Do we have a
> problem distinguishing between a 0-dimensional array and a
> 1-dimensional empty array?

Internally they're certainly different. I've just been sniffing around
the code a bit, and the main problem I see with trying to be more
rigorous about this is that array_out just prints '{}' for any
zero-element array, regardless of the recorded dimensionality. We could
reserve that notation to mean a 0-D array (which is what array_in reads
it as). But then we have to figure out what to print for other cases.
The only good idea that comes to mind is
[1:0]={}
(or variants of that depending on what the stored dimensions actually
are). array_in currently rejects that:

regression=# select '[1:0]={}'::int[];
ERROR: upper bound cannot be less than lower bound

but perhaps it wouldn't be too painful to tweak it to allow the case.

It appears to be fairly hard to actually get a non-zero-D empty array
into the system, so while this is pretty ugly I think it wouldn't affect
common usage.

Comments?

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2010-11-15 21:28:31 Bug in concurrency control in temporary GiST indexes
Previous Message Greg Stark 2010-11-15 17:11:08 Re: BUG #5748: Invalid oidvector data during binary recv