From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [WIP] ALTER ... OWNER TO ... CASCADE |
Date: | 2016-02-15 15:56:03 |
Message-ID: | 56C1F513.2040901@sigaev.ru |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> TBH, this sounds like a completely terrible idea. There are far too many
> sorts of dependencies across which one would not expect ownership to
> propagate; for example, use of a function in a view, or even just a
> foreign key dependency between two tables.
>
> I'm not even clear that there are *any* cases where this behavior is
> wanted, other than perhaps ALTER OWNER on an extension --- and even there,
> what you would want is altering the ownership of the member objects, but
> not everything that depends on the member objects.
>
> So basically, a generic CASCADE facility sounds like a lot of work to
> produce something that would seldom be anything but a foot-gun.
DELETE FROM or TRUNCATE could be a foot-gun too, but it's not a reason to
remove tham. I faced with problem when I tried to change owner of datadase with
all objects inside. Think, this feature could be useful although it should
restricted to superuser obly.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2016-02-15 16:02:55 | Re: Small PATCH: check of 2 Perl modules |
Previous Message | Dmitry Ivanov | 2016-02-15 15:44:54 | Re: [WIP] ALTER ... OWNER TO ... CASCADE |