Hi,
This is a preview patch - DON'T COMMIT IT TO HEAD!
What I've done in this patch is add the following:
ALTER AGGREGATE / OWNER TO
ALTER CONVERSION / OWNER TO
ALTER FUNCTION / OWNER TO
ALTER OPERATOR / OWNER TO
ALTER OPERATOR CLASS / OWNER TO
ALTER SCHEMA / OWNER TO
ALTER TYPE / OWNER TO
That mea
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Then I made it so that pg_dump will output an OWNER TO statement after
> every object creation.
Perhaps better to put these out towards the end of the dump, not right
after the creation of the object? Or is that what you're doing?
I would en
Perhaps better to put these out towards the end of the dump, not right
after the creation of the object? Or is that what you're doing?
I just inserted the ALTER OWNER statement between the CREATE and the
GRANTs. Why do you want them at the end of the dump?
I would envision the safest procedure
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I just inserted the ALTER OWNER statement between the CREATE and the
> GRANTs. Why do you want them at the end of the dump?
So that the initial owner is still owner when he does COPY, ALTER TABLE
ADD PRIMARY KEY, etc etc. Else you're gonna h
So that the initial owner is still owner when he does COPY, ALTER TABLE
ADD PRIMARY KEY, etc etc. Else you're gonna have problems.
I was thinking of doing all COPY and ALTER as superuser as well...
Or are you trying to make it work when run as non-super? Which is won't
since ALTER OWNER will req
Christopher Kings-Lynne wrote:
> Then I made it so that pg_dump will output an OWNER TO statement
> after every object creation.
I'd prefer it if OWNER TO were only added if it is actually necessary
(or there be some option to turn it off). I don't want to edit the
entire dump file if I want to
Christopher Kings-Lynne wrote:
> * Is there any reason there is no RENAME TO command for operators?
That might change the precedence of the operator and get you in a big
mess with stored expressions everywhere.
---(end of broadcast)---
TIP 3: if p
That might change the precedence of the operator and get you in a big
mess with stored expressions everywhere.
What if you could only do it on non-system operators?
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unre
I'd prefer it if OWNER TO were only added if it is actually necessary
(or there be some option to turn it off). I don't want to edit the
entire dump file if I want to restore the database into another SQL
database.
There is the existing --no-owner option, which this patch respects, same
as old
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> * Is there any reason there is no RENAME TO command for operators?
> That might change the precedence of the operator
... true ...
> and get you in a big mess with stored expressions everywhere.
Not with respect to
Christopher Kings-Lynne wrote:
> The old pg_dump would output a session auth, and then wouldn't bother
> changing it until necessary. However, with ALTER OWNER, I have to
> dump it for every object, even if it's the same user.
Well, the advantage of SET SESSION AUTHORIZATION is that it is SQL
co
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Christopher Kings-Lynne wrote:
> >> * Is there any reason there is no RENAME TO command for operators?
> >
> > That might change the precedence of the operator
>
> ... true ...
>
> > and get you in a big mess with stored expressions
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>>> That might change the precedence of the operator
>>
>> So I don't think this objection has a lot of weight.
> IIRC, it was the objection that you put forth when I last attempted to
Well, the advantage of SET SESSION AUTHORIZATION is that it is SQL
compliant, whereas ALTER OWNER is not. So I'm in favor of changing
nothing.
That, however is a highly theoretical, and quite non-practical
"solution". It leaves many of the world's postgresql database
non-upgradable and "fixin
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Well, the advantage of SET SESSION AUTHORIZATION is that it is SQL
> compliant, whereas ALTER OWNER is not. So I'm in favor of changing
> nothing.
That's a fair point, but you have to admit that it's a bit abstract
while Chris has a real problem he
That's a fair point, but you have to admit that it's a bit abstract
while Chris has a real problem he needs to solve. Our dumps are awfully
low on the SQL-compliance scale anyway :-(
We could keep around an option for dumping the auth statements instead
of alter statements perhaps.
Sure, but we'
- How does the above point affect full dumps that include schema and
data? In my proposal, the copy commands will run as the user running
the script, not the table owner anymore. Presumably, the user running
the script is a superuser. Given that it is possible for a table owner
to revoke th
There is one other consideration, and that is that current pg_dump likes
to set session_auth to user of object before outputting drop command,
when '-c' is specificed.
I propose that we eliminate that set session_auth as well. If the user
running the script is the owner of that object or a sup
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> There is one other consideration, and that is that current pg_dump likes
> to set session_auth to user of object before outputting drop command,
> when '-c' is specificed.
> I propose that we eliminate that set session_auth as well. If the u
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> This brings up a question for Chris, which is whether he's implemented
>> this in a way that forces the decision at pg_dump time, or whether
>> it is made during pg_restore.
> I've implented it exactly like comments are implemented. I just cr
I think this is wrong, primarily because it's gonna be seriously
incompatible with existing dump files. The existing technique is
that each TOC entry says who owns the object. You should use that
information and not have to rely on new additions to the file format.
Hrm. OK, i might be able to do
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> No, you don't. That allows non-superusers to give away object
>> ownership, which is well-established as a security hole; Unix
>> filesystems stopped doing it years ago.
> I worded that badly. I meant "allow a user to change the owner of
>
I worded that badly. I meant "allow a user to change the owner of
something to what it already is". ie. Just make the no-op allowed by
everyone. session_auth already does this.
Ah. Okay, no objection to that. (In fact I believe we put in the
special case for session_auth for exactly the sam
- How does the above point affect full dumps that include schema and
data? In my proposal, the copy commands will run as the user running
the script, not the table owner anymore. Presumably, the user running
the script is a superuser. Given that it is possible for a table owner
to revoke th
I think this is wrong, primarily because it's gonna be seriously
incompatible with existing dump files. The existing technique is
that each TOC entry says who owns the object. You should use that
information and not have to rely on new additions to the file format.
This is why GRANT/REVOKE has t
Any change someone who knows (or who can declare that we not fix
existing dumps) comment on this?
Chris
Christopher Kings-Lynne wrote:
I think this is wrong, primarily because it's gonna be seriously
incompatible with existing dump files. The existing technique is
that each TOC entry says who ow
26 matches
Mail list logo
