Re: machine-parseable object descriptions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: machine-parseable object descriptions
Date
Msg-id 14247.1363638708@sss.pgh.pa.us
Whole thread Raw
In response to machine-parseable object descriptions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: machine-parseable object descriptions  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> 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 of the
> object class; I propose the following list:

I'm okay with the proposed type names.

> After the object type we have the schema, which would be NULL for
> objects that don't belong to schemas (extensions, access methods, casts,
> languages, etc).

> Then we have the identity, which is a texualt representation of the
> other stuff needed to uniquely identify the object being referred to.

I think you should seriously consider dropping the separate "schema"
column and instead plugging the schema in at the appropriate place
in the identity string (which, evidently, is not always going to be
at the front).  Otherwise, how will client code know how to assemble the
schema onto the identity to make a usable name?  It's also pretty weird
that some of the names appearing in an identity will be fully qualified
but the most important one isn't.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Enabling Checksums
Next
From: Dimitri Fontaine
Date:
Subject: Re: machine-parseable object descriptions