Arturas Mazeika wrote:
> On 11/10/2010 05:32 AM, Tom Lane wrote:
> > Bruce Momjian writes:
> >
> >>> On 10/30/2010 7:33 PM, Dave Page wrote:
> >>>
> upgrade from a 32bit 8.3 server to a 64 bit 9.0 server, which isn't
> going to work without a dump/restore. With pg_upgrade, th
"Denis" wrote:
> nextval('NameSeq')
Does it work if you specify?:
nextval('"NameSeq"')
Generally, when the parameter is a character string representing an
identifier you must include quotes to preserve the capitalization.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postg
The following bug has been logged online:
Bug reference: 5749
Logged by: Denis
Email address: dolgalevde...@mail.ru
PostgreSQL version: 9.0.1
Operating system: Windows XP
Description:Case sensivity of names of sequences.
Details:
Hello.
I found some problem with seq
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
On Thu, 2010-11-11 at 18:20 +0200, Heikki Linnakangas wrote:
> On 11.11.2010 02:20, Jeff Davis wrote:
> > There is a problem with this patch. ReadRecord() not only modifies
> > global variables, it also modifies the location pointed to by "record",
> > which is later used to set "wasShutdown". How
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
On 11.11.2010 02:20, Jeff Davis wrote:
There is a problem with this patch. ReadRecord() not only modifies
global variables, it also modifies the location pointed to by "record",
which is later used to set "wasShutdown". How about if we only set
"wasShutdown" if there is no backup_label (because t
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
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
Details:
postgres=# create table a as sel
19 matches
Mail list logo
