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
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 |