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
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
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 name
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
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
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
