questions on ALTER TABLE ... OWNER

Started by Nonamealmost 24 years ago6 messages

nconway@klamath.dyndns.org

almost 24 years ago

Hi all,

Currently, ALTER TABLE ... OWNER will change the ownership of a table,
view, sequence or index -- despite the fact that its name hints that it
is only for 'altering tables'.

1) Is this behavior optimal? There is clearly a need to change the
ownership of relations other than tables, but it seems to me that
pushing this functionality into ALTER TABLE is unintuitive.

On the other hand, creating ALTER INDEX ... OWNER, ALTER SEQUENCE ...
OWNER, etc. seems like overkill.

2) Should we perhaps warn the user, if they use 'ALTER TABLE ... OWNER'
on a non-table relation?

3) Should this behavior be documented? Currently the docs on ALTER TABLE
... OWNER say nothing about changing the ownership of non-table
relations.

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Tom Lane

tgl@sss.pgh.pa.us

almost 24 years ago

In reply to: Noname (#1)

Re: questions on ALTER TABLE ... OWNER

nconway@klamath.dyndns.org (Neil Conway) writes:

Currently, ALTER TABLE ... OWNER will change the ownership of a table,
view, sequence or index -- despite the fact that its name hints that it
is only for 'altering tables'.

1) Is this behavior optimal? There is clearly a need to change the
ownership of relations other than tables, but it seems to me that
pushing this functionality into ALTER TABLE is unintuitive.

On the other hand, creating ALTER INDEX ... OWNER, ALTER SEQUENCE ...
OWNER, etc. seems like overkill.

Definitely overkill. I'd say tweak the docs and leave the code alone.

regards, tom lane

Noname

nconway@klamath.dyndns.org

almost 24 years ago

In reply to: Tom Lane (#2)

1 attachment(s)

Re: questions on ALTER TABLE ... OWNER

On Tue, Feb 19, 2002 at 02:03:38PM -0500, Tom Lane wrote:

nconway@klamath.dyndns.org (Neil Conway) writes:

Currently, ALTER TABLE ... OWNER will change the ownership of a table,
view, sequence or index -- despite the fact that its name hints that it
is only for 'altering tables'.

1) Is this behavior optimal? There is clearly a need to change the
ownership of relations other than tables, but it seems to me that
pushing this functionality into ALTER TABLE is unintuitive.

On the other hand, creating ALTER INDEX ... OWNER, ALTER SEQUENCE ...
OWNER, etc. seems like overkill.

Definitely overkill.

You're probably right -- although there is a symmetry between 'create
sequence', 'alter sequence', and 'drop sequence', rather than 'create
sequence', 'alter table' and 'drop sequence'.

BTW, the same semantic problems also apply to ALTER TABLE ... rename.

I'd say tweak the docs and leave the code alone.

Okay, fixed. I also corrected another minor inaccuracy in the ALTER
TABLE docs.

Bruce/Tom: Please apply for 7.2.1 and 7.3.

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Attachments:

alter_table_docs.patchtext/plain; charset=us-asciiDownload

*** ./doc/src/sgml/ref/alter_table.sgml.orig	Tue Feb 19 14:11:25 2002
--- ./doc/src/sgml/ref/alter_table.sgml	Tue Feb 19 14:23:33 2002
***************
*** 170,176 ****
     set the statistics-gathering target for subsequent
     <xref linkend="sql-analyze" endterm="sql-analyze-title"> operations.
     The <literal>RENAME</literal> clause causes the name of a table,
!    column, index, or sequence to change without changing any of the
     data. The data will remain of the same type and size after the
     command is executed.
     The ADD <replaceable class="PARAMETER">table_constraint_definition</replaceable> clause 
--- 170,176 ----
     set the statistics-gathering target for subsequent
     <xref linkend="sql-analyze" endterm="sql-analyze-title"> operations.
     The <literal>RENAME</literal> clause causes the name of a table,
!    column, index, sequence or view to change without changing any of the
     data. The data will remain of the same type and size after the
     command is executed.
     The ADD <replaceable class="PARAMETER">table_constraint_definition</replaceable> clause 
***************
*** 178,185 ****
     linkend="SQL-CREATETABLE" endterm="SQL-CREATETABLE-TITLE">. 
     The DROP CONSTRAINT <replaceable class="PARAMETER">constraint</replaceable> clause 
     drops all constraints on the table (and its children) that match <replaceable class="PARAMETER">constraint</replaceable>.
!    The OWNER clause changes the owner of the table to the user <replaceable class="PARAMETER">
!    new user</replaceable>.
    </para>
  
    <para>
--- 178,185 ----
     linkend="SQL-CREATETABLE" endterm="SQL-CREATETABLE-TITLE">. 
     The DROP CONSTRAINT <replaceable class="PARAMETER">constraint</replaceable> clause 
     drops all constraints on the table (and its children) that match <replaceable class="PARAMETER">constraint</replaceable>.
!    The OWNER clause changes the owner of the table, index, sequence or view to the
!    user <replaceable class="PARAMETER">new user</replaceable>.
    </para>
  
    <para>

Philip Warner

pjw@rhyme.com.au

almost 24 years ago

In reply to: Noname (#1)

Re: questions on ALTER TABLE ... OWNER

At 12:24 19/02/02 -0500, Neil Conway wrote:

Hi all,

Currently, ALTER TABLE ... OWNER will change the ownership of a table,
view, sequence or index -- despite the fact that its name hints that it

Does it automatically alter the ownership of items 'owned' by the table
(eg. PK indexes & serial sequences) when a table owner is altered?

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

Noname

nconway@klamath.dyndns.org

almost 24 years ago

In reply to: Philip Warner (#4)

Re: questions on ALTER TABLE ... OWNER

On Wed, Feb 20, 2002 at 07:39:18AM +1100, Philip Warner wrote:

At 12:24 19/02/02 -0500, Neil Conway wrote:

Hi all,

Currently, ALTER TABLE ... OWNER will change the ownership of a table,
view, sequence or index -- despite the fact that its name hints that it

Does it automatically alter the ownership of items 'owned' by the table
(eg. PK indexes & serial sequences) when a table owner is altered?

No, AFAICT. Should it?

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Bruce Momjian

pgman@candle.pha.pa.us

almost 24 years ago

In reply to: Noname (#3)

Re: questions on ALTER TABLE ... OWNER

Sorry, 7.3 only. Doc changes aren't really done for minor releases.

Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Neil Conway wrote:

On Tue, Feb 19, 2002 at 02:03:38PM -0500, Tom Lane wrote:

nconway@klamath.dyndns.org (Neil Conway) writes:

Currently, ALTER TABLE ... OWNER will change the ownership of a table,
view, sequence or index -- despite the fact that its name hints that it
is only for 'altering tables'.

1) Is this behavior optimal? There is clearly a need to change the
ownership of relations other than tables, but it seems to me that
pushing this functionality into ALTER TABLE is unintuitive.

On the other hand, creating ALTER INDEX ... OWNER, ALTER SEQUENCE ...
OWNER, etc. seems like overkill.

Definitely overkill.

You're probably right -- although there is a symmetry between 'create
sequence', 'alter sequence', and 'drop sequence', rather than 'create
sequence', 'alter table' and 'drop sequence'.

BTW, the same semantic problems also apply to ALTER TABLE ... rename.

I'd say tweak the docs and leave the code alone.

Okay, fixed. I also corrected another minor inaccuracy in the ALTER
TABLE docs.

Bruce/Tom: Please apply for 7.2.1 and 7.3.

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026