What about:
ALTER [OBJECT] RENAME TO [schema.]name [CASCADE]
This has somewhat less new syntax.
CASCADE would also move dependant objects.
Perhaps trigger functions should not be moved, since it
is not really obvious how to do this right.
Warning should be issued in this case.
Command basically
Wouldn't
ALTER [OBJECT] RENAME TO [schema.][name]
be a better?
After all, this is essentially a rename operation,
so maybe it is better to extend existing syntax...
5WD-02-Foundation-2003-09.pdf doesn't seem
to specify any renaming with ALTER TABLE...
---(end of broa
--On Freitag, Juni 10, 2005 21:20:33 +0200 [EMAIL PROTECTED] wrote:
Wouldn't
ALTER [OBJECT] RENAME TO [schema.][name]
be a better?
After all, this is essentially a rename operation,
so maybe it is better to extend existing syntax...
I don't think it's a good idea to merge two different sema
--On Donnerstag, Juni 09, 2005 10:17:33 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Hmm? You're planning to write into the relation in question. It's
hardly likely that the structure can be expected to remain virgin...
in practice I don't think we guarantee that even for read operations.
Oh,
--On Donnerstag, Juni 09, 2005 12:05:45 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
I don't think you have any choice about that --- I'm pretty sure that
there are places that assume a table's indexes are in the same schema
the table is. Constraints ditto.
Okay, then the consenus is to go for
Bernd Helmle <[EMAIL PROTECTED]> writes:
> --On Donnerstag, Juni 09, 2005 21:05:59 +0800 Christopher Kings-Lynne
>> Oh yes, you're probably right. Indexes should move though I think?
> Yes, i think so, too.
I don't think you have any choice about that --- I'm pretty sure that
there are places t
Bernd Helmle <[EMAIL PROTECTED]> writes:
> --On Mittwoch, Juni 08, 2005 14:49:56 -0400 Tom Lane <[EMAIL PROTECTED]>
> wrote:
>> Applying "const" to pointers that point to things that are not const,
>> as in
>>
>> + void
>> + ApplyTypeNamespace( Oid typeOid,
>> +const Relation rel,
--On Donnerstag, Juni 09, 2005 21:05:59 +0800 Christopher Kings-Lynne
<[EMAIL PROTECTED]> wrote:
Oh yes, you're probably right. Indexes should move though I think?
Yes, i think so, too.
--
Bernd
---(end of broadcast)---
TIP 5: Have you ch
They should all be moved. Remember nasties like indexes should be moved
as well as toast tables.
Oh, i thought toast tables should live in the pg_toast namespace?
Oh yes, you're probably right. Indexes should move though I think?
Chris
---(end of broadcast)
--On Mittwoch, Juni 08, 2005 14:48:55 -0400 Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
On Wed, Jun 08, 2005 at 08:25:12PM +0200, Bernd Helmle wrote:
One issue that comes to my mind is what to do when dealing with tables
that have assigned triggers and sequences (serials). Do we want to move
t
--On Mittwoch, Juni 08, 2005 14:49:56 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
The code seems fairly schizoid about whether the operation is an "alter
namespace" or a "rename". Please be consistent. I'd say it is *not*
a rename, but I suppose you could make an argument the other way ...
No
--On Donnerstag, Juni 09, 2005 10:33:08 +0800 Christopher Kings-Lynne
<[EMAIL PROTECTED]> wrote:
One issue that comes to my mind is what to do when dealing with tables
that have assigned triggers and sequences (serials). Do we want to move
them as well or leave them in the source namespace?
T
One issue that comes to my mind is what to do when dealing with tables
that have assigned triggers and sequences (serials). Do we want to move
them as well or leave them in the source namespace?
They should all be moved. Remember nasties like indexes should be moved
as well as toast tables.
Bernd Helmle <[EMAIL PROTECTED]> writes:
> You can find a preliminary patch attached to this posting and i'm looking
> for comments, critics and perhaps some proposals for improvements /
> necessary changes i didn't consider yet.
The code seems fairly schizoid about whether the operation is an "
On Wed, Jun 08, 2005 at 08:25:12PM +0200, Bernd Helmle wrote:
> One issue that comes to my mind is what to do when dealing with tables that
> have assigned triggers and sequences (serials). Do we want to move them as
> well or leave them in the source namespace?
I'd think it's important that th
I've took a look at the TODO item
Allow objects to be moved to different schemas
I've done some code so far which implements the syntax
ALTER [OBJECT] name SET SCHEMA name
where OBJECT currently is
SEQUENCE
TABLE
FUNCT
16 matches
Mail list logo
