Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

2016-02-16 Thread Vladimir Borodin
> 16 февр. 2016 г., в 18:20, Alvaro Herrera > написал(а): > > Vladimir Borodin wrote: > >>> Moreover, the use case you've sketched (ie, change ownership of all >>> objects inside a database) doesn't actually have anything to do with >>> following dependencies. It's

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

2016-02-16 Thread Alvaro Herrera
Vladimir Borodin wrote: > > Moreover, the use case you've sketched (ie, change ownership of all > > objects inside a database) doesn't actually have anything to do with > > following dependencies. It's a lot closer to REASSIGN OWNED ... in > > fact, it's not clear to me why REASSIGN OWNED

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

2016-02-16 Thread Dmitry Ivanov
> Sometimes I hit the following. You have created a database and schema inside > it from the superuser (i.e. postgres). Than you want to change ownership of > whole database to another user (i.e. alice), but only this database, not > all other objects in all other databases. Actually, it skips

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

2016-02-16 Thread Oleg Bartunov
On Mon, Feb 15, 2016 at 7:25 PM, Tom Lane wrote: > Teodor Sigaev writes: > >> 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

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

2016-02-16 Thread Vladimir Borodin
> 15 февр. 2016 г., в 19:25, Tom Lane написал(а): > > Teodor Sigaev writes: >>> 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

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

2016-02-15 Thread Tom Lane
Teodor Sigaev writes: >> 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

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

2016-02-15 Thread Teodor Sigaev
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*

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

2016-02-15 Thread Dmitry Ivanov
> Dmitry Ivanov writes: > > As of now there's no way to transfer the ownership of an object and all > > its > > dependent objects in one step. One has to manually alter the owner of each > > object, be it a table, a schema or something else. > > TBH, this sounds like a

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

2016-02-15 Thread Tom Lane
Dmitry Ivanov writes: > As of now there's no way to transfer the ownership of an object and all its > dependent objects in one step. One has to manually alter the owner of each > object, be it a table, a schema or something else. TBH, this sounds like a completely

[HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

2016-02-15 Thread Dmitry Ivanov
Hi hackers, Recently I've been working on a CASCADE option for ALTER ... OWNER TO statement. Although it's still a working prototype, I think it's time to share my work. Introduction As of now there's no way to transfer the ownership of an object and all its dependent objects