Robert Haas writes:
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.
On Tue, Feb 8, 2011 at 6:54 PM, Tom Lane wrote:
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.
Preferences anyone?
The closest exstant parallel is probably: 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.
Preferences anyone?
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.
semantic standpoint.
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.
Hmm, that's an interesting thought. It'd require rather morebe 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.
refactoring of the grammar and the parsetree representation than I care
to get into right now, but that could be a foreseeable extension in
future. On the other hand, it's not *that* exciting, and if multi ADD
isn't supported in the very first version then probably nobody will ever
want to rely on it in extension scripts.
I'm still finding that the "document in one place" angle is the most
compelling argument to me.
regards, tom lane
