From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4] |
Date: | 2004-01-20 16:50:48 |
Message-ID: | 20040120124911.F930@ganymede.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 20 Jan 2004, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> > On Mon, 19 Jan 2004, Tom Lane wrote:
> >> in particular, what SQL command is it trying to execute when it chokes?
>
> > The function is executing:
>
> > EXECUTE ''update pg_attribute set attnotnull = false from pg_class where
> > pg_attribute.attrelid = pg_class.oid and pg_class.relname = '' ||
> > quote_literal(table_name) ||'' and pg_attribute.attname = '' ||
> > quote_literal(column_name);
>
> Well, no wonder. You have to be superuser to do that, and it's a pretty
> bad idea even then.
>
> We do have ALTER TABLE ... SET/DROP NOT NULL since 7.3, so hacking
> pg_attribute directly isn't necessary for this anymore.
So, if we replace that with:
ALTER TABLE table_name ALTER column_name DROP NOT NULL; ?
should be good to go? still not as clean as doing the straight DROP
COLUMN, but its a fast fix ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-01-20 17:07:42 | Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4] "permissions problem" with pl/pgsql function ) |
Previous Message | Tom Lane | 2004-01-20 16:36:26 | Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4] "permissions problem" with pl/pgsql function ) |