Christopher Kings-Lynne writes:
> > The command is: ALTER THING name AUTHORIZATION username; (This is
> > consistent with the CREATE SCHEMA syntax. Anyone like OWNER better?)
> k
> WHy not copy the exiting ALTER TABLE / OWNER TO syntax?
Because the standard specifies the syntax CREATE SCHEMA na
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Right, there's a global variable that stores the database name, but that
> will have to disappear. You'll have to look it up in the catalog like
> everything else.
That answer is okay as long as we don't need to get at the value while
outside any tra
Tom Lane writes:
> A few. Moving a table across schemas would require moving its indexes
> and rowtype as well; conversely you should forbid moving the indexes and
> rowtype by themselves, or altering their owners separately from the
> table, or renaming the rowtype by itself.
Right. This is mo
> The command is: ALTER THING name AUTHORIZATION username; (This is
> consistent with the CREATE SCHEMA syntax. Anyone like OWNER better?)
k
WHy not copy the exiting ALTER TABLE / OWNER TO syntax?
Chris
---(end of broadcast)---
TIP 8: explain an
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Are there any tricky problems with any of these operations?
A few. Moving a table across schemas would require moving its indexes
and rowtype as well; conversely you should forbid moving the indexes and
rowtype by themselves, or altering their owners
We only have sporadic support to rename objects, change the owner of
objects, and no support to change the schema of an object. So how about a
big bang to add support for these three operations for every object where
it is applicable? I hope to do it without a separate parse structure and
routine
