Greg Stark 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 wi
On Mon, Nov 15, 2010 at 4:51 PM, Tom Lane wrote:
> 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 disting
I wrote:
> Yeb Havinga 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
Yeb Havinga 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. oidvector and
int2vector are different though. Which is why this should be fixe
On 2010-11-15 11:40, Heikki Linnakangas wrote:
On 15.11.2010 12:08, Yeb Havinga wrote:
On 2010-11-11 17:02, Heikki Linnakangas wrote:
On 11.11.2010 17:48, Tom Lane wrote:
"Yeb Havinga" writes:
postgres=# create table a as select ''::oidvector;
SELECT 1
postgres=# copy a to '/tmp/test' with bi
On 15.11.2010 12:08, Yeb Havinga wrote:
On 2010-11-11 17:02, Heikki Linnakangas wrote:
On 11.11.2010 17:48, Tom Lane wrote:
"Yeb Havinga" writes:
postgres=# create table a as select ''::oidvector;
SELECT 1
postgres=# copy a to '/tmp/test' with binary;
COPY 1
postgres=# copy a from '/tmp/test'
On 2010-11-11 17:02, Heikki Linnakangas wrote:
On 11.11.2010 17:48, Tom Lane wrote:
"Yeb Havinga" writes:
postgres=# create table a as select ''::oidvector;
SELECT 1
postgres=# copy a to '/tmp/test' with binary;
COPY 1
postgres=# copy a from '/tmp/test' with binary;
ERROR: invalid oidvector d
Yeb Havinga writes:
> Anyway I now have troubles to make a good test case to trip the lbound
> check.
I don't believe you ever did have a test case that would trip the lbound
check. What was failing was the ARR_NDIM == 1 check. If you were to
look at the array in gdb, the apparent value of the
On 2010-11-11 17:56, Tom Lane wrote:
Yeb Havinga writes:
If there is going to be a patch fixing things, the value
'{"1"}'::oidvector[] can't be exported and imported through binary send
recv as well.
That's pilot error, nothing more nor less. (oidvector != oidvector[])
We're not trying to imp
Yeb Havinga writes:
> If there is going to be a patch fixing things, the value
> '{"1"}'::oidvector[] can't be exported and imported through binary send
> recv as well.
That's pilot error, nothing more nor less. (oidvector != oidvector[])
regards, tom lane
--
Sent vi
On 2010-11-11 17:14, Heikki Linnakangas wrote:
On 11.11.2010 18:11, Yeb Havinga wrote:
We're currently reading data from a remote pg_statistics, in particular
stavalues1.. etc. Even when our own user defined relations do not make
use of oidvectors (or intvectors), during testing on arbitrary
pg_
Heikki Linnakangas writes:
> On 11.11.2010 18:17, Tom Lane wrote:
>> BTW ... it strikes me there's another inconsistency between oidvectorin
>> and oidvectorrecv, namely that the former enforces a maximum of
>> FUNC_MAX_ARGS elements whereas the latter has no such limit.
> Yes, it does:
Oh, neve
On 11.11.2010 18:17, Tom Lane wrote:
BTW ... it strikes me there's another inconsistency between oidvectorin
and oidvectorrecv, namely that the former enforces a maximum of
FUNC_MAX_ARGS elements whereas the latter has no such limit.
Yes, it does:
/* check length for consistency with
BTW ... it strikes me there's another inconsistency between oidvectorin
and oidvectorrecv, namely that the former enforces a maximum of
FUNC_MAX_ARGS elements whereas the latter has no such limit. Should we
do something about that, and if so what? It wouldn't be too hard to get
rid of the former'
On 11.11.2010 18:11, Yeb Havinga wrote:
On 2010-11-11 16:48, Tom Lane wrote:
"Yeb Havinga" writes:
postgres=# create table a as select ''::oidvector;
SELECT 1
postgres=# copy a to '/tmp/test' with binary;
COPY 1
postgres=# copy a from '/tmp/test' with binary;
ERROR: invalid oidvector data
The
Heikki Linnakangas writes:
> On 11.11.2010 17:48, Tom Lane wrote:
>> The problem seems to be that array_recv passes back a zero-dimensional
>> array, *not* a 1-D array, when it observes that the input has no
>> elements. A zero-D array is not part of the subset of possible arrays
>> that we allow
On 2010-11-11 16:48, Tom Lane wrote:
"Yeb Havinga" writes:
postgres=# create table a as select ''::oidvector;
SELECT 1
postgres=# copy a to '/tmp/test' with binary;
COPY 1
postgres=# copy a from '/tmp/test' with binary;
ERROR: invalid oidvector data
The problem seems to be that array_recv pas
On 11.11.2010 17:48, Tom Lane wrote:
"Yeb Havinga" writes:
postgres=# create table a as select ''::oidvector;
SELECT 1
postgres=# copy a to '/tmp/test' with binary;
COPY 1
postgres=# copy a from '/tmp/test' with binary;
ERROR: invalid oidvector data
The problem seems to be that array_recv pa
"Yeb Havinga" writes:
> postgres=# create table a as select ''::oidvector;
> SELECT 1
> postgres=# copy a to '/tmp/test' with binary;
> COPY 1
> postgres=# copy a from '/tmp/test' with binary;
> ERROR: invalid oidvector data
The problem seems to be that array_recv passes back a zero-dimensional
On 11.11.2010 16:30, Yeb Havinga wrote:
The following bug has been logged online:
Bug reference: 5748
Logged by: Yeb Havinga
Email address: yebhavi...@gmail.com
PostgreSQL version: 9.0.1
Operating system: Linux
Description:Invalid oidvector data during binary recv
D
20 matches
Mail list logo
