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: 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: (view raw, whole thread or download thread mbox)
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
(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.


			regards, tom lane

In response to

pgsql-bugs by date

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

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