Tom Lane wrote:
> Alvaro Herrera writes:
> > One change I made was to move all the new code from dependency.c into
> > objectaddress.c. The only reason it was in dependency.c was that
> > getObjectDescription was there in the first place; but it doesn't seem
> > to me that it really belongs there
Alvaro Herrera writes:
> One change I made was to move all the new code from dependency.c into
> objectaddress.c. The only reason it was in dependency.c was that
> getObjectDescription was there in the first place; but it doesn't seem
> to me that it really belongs there. (Back when it was first
Alvaro Herrera writes:
> The new identity column is amazingly verbose on things like pg_amproc entries:
> 10650 | 1 (pg_catalog.point, pg_catalog.point) of pg_catalog.point_ops for
> gist:
> pg_catalog.gist_point_consistent(pg_catalog.internal,pg_catalog.point,integer,pg_catalog.oid,pg_catalog
Alvaro Herrera writes:
> All in all, I'm happy with this and I'm considering committing it as
> soon as we agree on the set of columns. I'm mildly on the side of
> removing the separate schema column and keeping name, so we'd have
> type/name/identity.
I would prefer that we keep the schema colu
Alvaro Herrera wrote:
> .. and here's the patch.
I forgot an example involving the funniest of all object classes:
default ACLs. Here it is.
alvherre=# create role rol1;
CREATE ROLE
alvherre=# create role rol2;
CREATE ROLE
alvherre=# create schema rol1 authorization rol1;
CREATE SCHEMA
alvherre=
.. and here's the patch.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
*** a/src/backend/catalog/dependency.c
--- b/src/backend/catalog/dependency.c
***
*** 67,72
--- 67,73
#include "commands/trigger.
Dimitri Fontaine wrote:
> Tom Lane writes:
> > I could also live with keeping the schema column as proposed, if people
> > think it has a use, but letting it be redundant with a schema name
> > included in the identity string. But it seems like a bad idea to try to
> > shear schema off of identit
On 2013.03.18 1:03 PM, Alvaro Herrera wrote:
For Dimitri's patch to add support for dropped objects in event
triggers, there's an open question about how to report objects that are
being dropped in a tabular format.
Now that JSON is a built-in type with 9.2+, could we not perhaps use that to
r
Tom Lane writes:
> I could also live with keeping the schema column as proposed, if people
> think it has a use, but letting it be redundant with a schema name
> included in the identity string. But it seems like a bad idea to try to
> shear schema off of identity.
+1
Use case for keeping the e
Alvaro Herrera writes:
> For Dimitri's patch to add support for dropped objects in event
> triggers, there's an open question about how to report objects that are
> being dropped in a tabular format. What I proposed last had three
> columns: (type, schema, identity). The "type" is a description
Alvaro Herrera writes:
> For Dimitri's patch to add support for dropped objects in event
> triggers, there's an open question about how to report objects that are
> being dropped in a tabular format. What I proposed last had three
> columns: (type, schema, identity). The "type" is a description
For Dimitri's patch to add support for dropped objects in event
triggers, there's an open question about how to report objects that are
being dropped in a tabular format. What I proposed last had three
columns: (type, schema, identity). The "type" is a description of the
object class; I propose t
12 matches
Mail list logo
