Re: fix schema ownership on first connection preliminary - Mailing list pgsql-patches

From Fabien COELHO
Subject Re: fix schema ownership on first connection preliminary
Date
Msg-id Pine.LNX.4.58.0408101119360.1998@sablons.cri.ensmp.fr
Whole thread Raw
In response to Re: fix schema ownership on first connection preliminary patch v2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
> > I have added the v2 version of this patch to the patch queue (attached).
>
> I do apologize for not having looked at this patch sooner, but it's been
> at the bottom of the priority queue :-(

No need to apoligize.

> In general I do not like the approach of using SPI for this. [...]

Ok.

Well, my actual motivation for using SPI is to write 3 lines of SQL were
the intent is obvious instead of 60 lines of obscure C. I'm just lazy.

> Also, since we already have AlterSchemaOwner coded at the C level,
> the original rationale of not wanting to add code has been rendered
> moot.

Well, I did not noticed this good function.

> I do not like the hardwired assumption that userID 1 exists and is
> a superuser.

With UNIX, there is a pretty hard assumption that root is number 0, and I
assumed - wrongly - that the same line of reasonning applied to pg.

> The code is also broken to assume that ID 1 is the owner of the public
> schema in the source database (though this part is at least easy to fix,
> and would go away anyway if using AlterSchemaOwner).

My implicit assumption was that if it is not 1, it means that someone
decide to give some template1 schemas to someone, and I don't have to
change that.

> However, enough about implementation deficiencies.

Anyway, it is good to know.

> Did we really have consensus that the system should do this in the first
> place?

I'm convinced that the current status is not appropriate, but that does
not mean that what the patch suggests a good fix.

The current status is that when you do "CREATE DATABASE foo WITH OWNER
calvin", user calvin which "owns" the database is prevented from
manipulating the "public" schema...

The underlying question is "what is a database owner?". My feeling is that
it is like a unix-directory owner, that is someone who can do whatever it
likes at home, but cannot change the system (/bin, /lib).

> I was only about halfway sold on the notion of changing public's
> ownership. I especially dislike the detail that it will alter the
> ownership of *all* non-builtin schemas, not only "public".  If someone
> has added special-purpose schemas to template1, it seems unlikely that
> this is the behavior they'd want.

Mmm... my assumption here was that either it is a "system" schema, and it
is special, or it is not, and then it is not special. But it is only an
assumption, which makes sense with the "unix-like" owner approach.

> I think we should leave the behavior alone, at least for this release
> cycle.

Ok. Thanks for your comments.

--
Fabien Coelho - coelho@cri.ensmp.fr

pgsql-patches by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: psql - missing tab-completion support for tablespaces
Next
From: Fabien COELHO
Date:
Subject: Re: fix schema ownership on first connection preliminary