From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sql_drop Event Trigger |
Date: | 2013-03-04 16:49:17 |
Message-ID: | 20130304164916.GF9507@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dimitri Fontaine escribió:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > Another question. If I do ALTER TABLE foo DROP COLUMN bar, do we need
> > to fire an event trigger for the dropped column? Right now we don't,
> > ISTM we should. And if we want that, then the above set of three
> > properties doesn't cut it.
>
> Do we paint ourselves in a corner by not supporting columns in the first
> release?
Well, the main distinction is that there's no space to refer to them in
the current implementation, for lack of objectSubId or (more likely)
column name.
> Table columns are proper SQL level objects in that they have their own
> catalog entry and OID and a set of commands to manage them, but that set
> of command is in fact a *subset* of ALTER TABLE.
Table columns do not have OIDs; you refer to them by
(objectId, objectSubId). The latter is an integer that references
pg_attribute.attnum.
I am only wondering about ways to drop things at present, without
concern for whether it's a straight DROP FOO command or ALTER, etc.
> It feels like drifting
> a little more into the land of exposing PostgreSQL internals in a way,
> so I'm not too sure about the proper answer here.
Mumble.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2013-03-04 17:21:45 | Re: Hold all commits! |
Previous Message | Robert Haas | 2013-03-04 16:38:57 | Re: Suggested new CF status: "Pending Discussion" |