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
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-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
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
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
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
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
While hacking on the GiST insertion algorithm, I noticed a bug with
temporary GiST indexes. The scan algorithm uses LSNs to detect a
concurrent page split, but for a temporary index, we just use a constant
LSN on the assumption that there can't be anyone else modifying the
index concurrently. B
The following bug has been logged online:
Bug reference: 5754
Logged by: David Fetter
Email address: da...@fetter.org
PostgreSQL version: 8.4+
Operating system: All
Description:CTE optimization fails to account for side effects
Details:
Here's how to reproduce:
BEG
"David Fetter" writes:
> CREATE SEQUENCE my_seq;
> WITH t AS (SELECT nextval('my_seq')) VALUES(1);
> SELECT currval('my_seq');
> ERROR: currval of sequence "my_seq" is not yet defined in this session
> What's happened is that the optimization didn't account for the idea that a
> SELECT might ha
10 matches
Mail list logo
