Re: array surprising behavior - Mailing list pgsql-hackers

From Joe Conway
Subject Re: array surprising behavior
Date
Msg-id 402142B5.3050800@joeconway.com
Whole thread Raw
In response to array surprising behavior  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Question on database backup  (Michael Brusser <michael@synchronicity.com>)
Beta freeze? (was Re: array surprising behavior)  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-hackers
Alvaro Herrera wrote:
> I think this is most surprising behavior -- shouldn't the UPDATE raise
> an error?

Surprising, but not new (probably has been there back to the Berkley 
code), and has come up before on one of the lists (I think it might even 
have been pgsql-bugs).

regression=# select version();    version
------------------------------------------------------------------------ PostgreSQL 7.3.5 on i686-pc-linux-gnu,
compiledby GCC gcc (GCC) 3.2.2 
 
20030222 (Red Hat Linux 3.2.2-5)
(1 row)

regression=# create table foo (a int[]);
CREATE TABLE
regression=# insert into foo values (null);
INSERT 1104092 1
regression=# update foo set a[3] = '42';
UPDATE 1
regression=# select a, a is null from foo; a | ?column?
---+----------   | t
(1 row)

I'm still hoping to scrounge up the time to continue working on arrays 
for 7.5, including figuring out how to deal with this.

Joe




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint
Next
From: Neil Conway
Date:
Subject: Re: implemented missing bitSetBit() and bitGetBit()