On Tue, Feb 8, 2011 at 6:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dimitri Fontaine <dimi...@2ndquadrant.fr> writes: >> Tom Lane <t...@sss.pgh.pa.us> writes: >>> (I was vaguely imagining that it could share most of the COMMENT >>> infrastructure --- but haven't looked yet). > >> Well the code footprint is quite small already. > > Having now looked at it a bit closer, I think the syntax choice is a > complete wash from an implementation standpoint: either way, we'll have > a list of bison productions that build AlterObjectExtensionStmt nodes, > and it goes through the same way after that. I do think that the > implementation will be a lot more compact if it relies on the COMMENT > infrastructure (ie, get_object_address), but that's an independent > choice. > > So really it boils down to which syntax seems more natural and/or easier > to document. As I said, I think a centralized ALTER EXTENSION syntax > has some advantages from the documentation standpoint; but that's not a > terribly strong argument, especially given that Dimitri has already done > a patch to document things the other way. > > Preferences anyone?
The closest exstant parallel is probably: ALTER SEQUENCE foo OWNED BY bar; I think paralleling that would probably be the most SQL-ish thing to do, but I can't get excited about it. The ALTER EXTENSION syntax will be a lot more self-contained, with all of it one part of the grammar and one part of the documentation. And you could even allow multiple objects: ALTER EXTENSION extension_name ADD object-description [, ...]; Which might be handy. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
