--On 1. Oktober 2009 17:22:06 -0400 Alvaro Herrera
wrote:
- The patch as is has still some locking problems (AlterRoleSet()
has a XXX about that): I've managed to create dead entries for a
role or a database in pg_db_role_setting while altering and dropping
a role/database in two concurrent
--On 1. Oktober 2009 17:22:06 -0400 Alvaro Herrera
wrote:
- ALTER ROLE ... IN DATABASE is missing some documentation. If you
want, i can work on this.
Please.
Here's a patch for this. I've kept it separately, so it's easier for you to
merge it into
your version.
--
Thanks
Be
Bernd Helmle escribió:
>
>
> --On 30. September 2009 13:19:53 -0400 Alvaro Herrera
> wrote:
>
> >>I think it would be helpful if you could post ONE patch with all the
> >>changes and all the new files in the diff. AIUI, "the" patch is now
> >>split across three separate emails. :-(
> >
> >Tha
--On 30. September 2009 13:19:53 -0400 Alvaro Herrera
wrote:
I think it would be helpful if you could post ONE patch with all the
changes and all the new files in the diff. AIUI, "the" patch is now
split across three separate emails. :-(
That's correct, here it is.
Some additional not
Tom Lane escribió:
> Alvaro Herrera writes:
> > FWIW I came up with a preliminary patch for a new psql command \dus that
> > shows settings. It takes a pattern that's used to constrain on roles.
> > Thus there is no way to view settings for a database. If there's a need
> > for that we could use
Alvaro Herrera writes:
> FWIW I came up with a preliminary patch for a new psql command \dus that
> shows settings. It takes a pattern that's used to constrain on roles.
> Thus there is no way to view settings for a database. If there's a need
> for that we could use another command, say \dls.
Tom Lane escribió:
> BTW, have we thought much about the simplest possible solution,
> which is to not have the view? How badly do we need it? Seems
> like dropping the functionality into a psql \d command might be
> a viable alternative.
FWIW I came up with a preliminary patch for a new psql c
On Wed, Sep 30, 2009 at 10:34 AM, Alvaro Herrera
wrote:
> And here's the last necessary bit, which is pg_dump support for all
> this.
I think it would be helpful if you could post ONE patch with all the
changes and all the new files in the diff. AIUI, "the" patch is now
split across three separa
Alvaro Herrera writes:
> Tom Lane escribió:
>> Hmm ... I would kind of think that --roles-only should suppress this too.
>> Otherwise you're going to be dumping commands that might refer to
>> nonexistent databases.
> Hmm. The problem I have with this idea is that the only way to dump the
> per-
Tom Lane escribió:
> Alvaro Herrera writes:
> > And here's the last necessary bit, which is pg_dump support for all
> > this.
>
> > + /* Dump role/database settings */
> > + if (!tablespaces_only)
> > + {
> > + if (server_version >= 80500)
> > +
Tom Lane escribió:
> Alvaro Herrera writes:
> > And here's the last necessary bit, which is pg_dump support for all
> > this.
>
> > + /* Dump role/database settings */
> > + if (!tablespaces_only)
> > + {
> > + if (server_version >= 80500)
> > +
Alvaro Herrera writes:
> And here's the last necessary bit, which is pg_dump support for all
> this.
> + /* Dump role/database settings */
> + if (!tablespaces_only)
> + {
> + if (server_version >= 80500)
> + dump
And here's the last necessary bit, which is pg_dump support for all
this.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
*** src/bin/pg_dump/pg_dumpall.c 11 Jun 2009 14:49:07 - 1.126
--- src/b
--On 28. September 2009 19:02:34 -0400 Alvaro Herrera
wrote:
Seems Alvaro forgot to include pg_db_role_setting.h, it doesn't
compile anymore with this error:
Here they are.
I'll see if i can get to it tonight. I'm currently travelling, so it could
be delayed until Thursday.
--
Thanks
Bernd Helmle escribió:
> Seems Alvaro forgot to include pg_db_role_setting.h, it doesn't
> compile anymore with this error:
Here they are.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
/*
* pg_db_role_setting.c
*
Bernd Helmle escribió:
> Seems Alvaro forgot to include pg_db_role_setting.h, it doesn't
> compile anymore with this error:
Huh, you're right, I did :-( Let me unpack the laptop ...
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command
On Sep 27, 2009, at 9:19 PM, Tom Lane wrote:
What we seem to be lacking in this case is a good tech-speak
option for the underlying catalog name. I'm still not happy
with having a catalog and a view that are exactly the same
except for "s", especially since as Alvaro notes that won't
lead to des
--On 27. September 2009 21:59:37 -0400 Robert Haas
wrote:
Bernd,
Can you review this new version and mark this as Ready for Committer
if it looks OK, or else respond with comments and set it back to
Waiting on Author?
Seems Alvaro forgot to include pg_db_role_setting.h, it doesn't compil
Robert Haas writes:
> That seems to me to be just confusing the issue. Now the table name
> and the view name are just totally different with no obvious
> connection between them. We have enough nonsense of this type already
> (e.g. pg_stats vs. pg_statistic; pg_authid vs. pg_roles vs.
> pg_shad
On Fri, Sep 25, 2009 at 8:05 PM, Alvaro Herrera
wrote:
> Alvaro Herrera escribió:
>
>> I think it can be solved by splitting OptRoleElem in a set of
>> productions for ALTER and a superset of that for ALTER. I'll go try
>> that.
>
> Right, that works. Updated patch attached; should solve the iss
On Sat, Sep 26, 2009 at 11:44 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> The problem of having both a table and a closely related view is,
>> IME, one that comes up a lot. I think you just need to pick a
>> convention and stick with it. Mine is to append "_view" to the
>> table name.
Robert Haas escribió:
> The problem of having both a table and a closely related view is,
> IME, one that comes up a lot. I think you just need to pick a
> convention and stick with it. Mine is to append "_view" to the
> table name.
That would make the difference clear, but since what the user n
On Sep 26, 2009, at 11:59 AM, Tom Lane wrote:
Alvaro Herrera writes:
Right, that works. Updated patch attached; should solve the issues
raised in the thread. I renamed the catalog pg_db_role_setting as
suggested by Tom.
...
I have also added a view, whose only purpose is to convert the role
Alvaro Herrera writes:
> Right, that works. Updated patch attached; should solve the issues
> raised in the thread. I renamed the catalog pg_db_role_setting as
> suggested by Tom.
> ...
> I have also added a view, whose only purpose is to convert the role and
> database OIDs into names. It's be
Tom Lane escribió:
> Gurjeet Singh writes:
> > ON instead of second ALTER looks better, and IMHO DATABASE should
> > be optional too:
>
> > ALTER ROLE [ON DATABASE ] SET TO ;
>
> IN, not ON.
This creates a parser conflict with
CREATE ROLE foo IN ROLE bar
I think it can be solved by splittin
On Wed, Sep 23, 2009 at 3:03 PM, Bernd Helmle wrote:
>
>
> --On 23. September 2009 14:10:39 -0400 Tom Lane wrote:
>
>> FWIW, I looked the patch over quickly, and I think it will be fine once
>> Bernd's comments are addressed. In particular I agree with the
>> objection to the name "pg_setting" a
--On 23. September 2009 14:10:39 -0400 Tom Lane wrote:
FWIW, I looked the patch over quickly, and I think it will be fine once
Bernd's comments are addressed. In particular I agree with the
objection to the name "pg_setting" as being confusingly close to
"pg_settings". But "pg_user_setting"
Alvaro Herrera writes:
> Robert Haas escribió:
>> So here's the followup question - do you intend to do one of those
>> things for this CommitFest, or should we mark this as Returned with
>> Feedback once Bernd posts the rest of his review?
> What feedback is it supposed to be returned with? Pre
Gurjeet Singh writes:
> ON instead of second ALTER looks better, and IMHO DATABASE should
> be optional too:
> ALTER ROLE [ON DATABASE ] SET TO ;
IN, not ON.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
On Tue, Sep 22, 2009 at 4:16 AM, Bernd Helmle wrote:
>
>
> --On 21. September 2009 13:42:21 +0200 Bernd Helmle
> wrote:
>
>
>>
>> --On 20. September 2009 22:56:53 -0400 Robert Haas
>> wrote:
>>
>> So is this ready to commit, or what?
>>>
>>
>> Not yet, see the comments Alvaro did upthread. Ple
On Mon, Sep 21, 2009 at 12:23 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> So here's the followup question - do you intend to do one of those
>> things for this CommitFest, or should we mark this as Returned with
>> Feedback once Bernd posts the rest of his review?
>
> What feedback is i
--On 21. September 2009 13:42:21 +0200 Bernd Helmle
wrote:
--On 20. September 2009 22:56:53 -0400 Robert Haas
wrote:
So is this ready to commit, or what?
Not yet, see the comments Alvaro did upthread. Please note that i'm still
reviewing this one and i hope to post results tomorrow (
Alvaro Herrera escribió:
> What feedback is it supposed to be returned with? Precisely what I
> wanted is some feedback on the general idea. Brendan's "I like the
> approach" is good, but is it enough to deter a later veto from someone
> else?
s/Brendan/Bernd/
--
Alvaro Herrera
Robert Haas escribió:
> So here's the followup question - do you intend to do one of those
> things for this CommitFest, or should we mark this as Returned with
> Feedback once Bernd posts the rest of his review?
What feedback is it supposed to be returned with? Precisely what I
wanted is some f
On Mon, Sep 21, 2009 at 12:21 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> > Here's a first shot on this for my current review round. Patch needed to
>> > re-merged into current CVS HEAD due to some merge conflicts, i've also
>> > adjusted the regression tests (minor). On a first look, i
--On 20. September 2009 22:56:53 -0400 Robert Haas
wrote:
So is this ready to commit, or what?
Not yet, see the comments Alvaro did upthread. Please note that i'm still
reviewing this one and i hope to post results tomorrow (there wasn't plenty
of free time over the weekend, i'm sorry).
Robert Haas escribió:
> > Here's a first shot on this for my current review round. Patch needed to
> > re-merged into current CVS HEAD due to some merge conflicts, i've also
> > adjusted the regression tests (minor). On a first look, i like the patch
> > (especially the code for the utility comman
On Fri, Sep 18, 2009 at 4:03 PM, Bernd Helmle wrote:
>
>
> --On 25. August 2009 22:17:38 -0400 Alvaro Herrera
> wrote:
>
>> I'm just posting in case somebody has thoughts on the UI part of it.
>>
>> Other things that need fixed:
>>
>> - need to figure out locking for roles; this stuff must be syn
--On 25. August 2009 22:17:38 -0400 Alvaro Herrera
wrote:
I'm just posting in case somebody has thoughts on the UI part of it.
Other things that need fixed:
- need to figure out locking for roles; this stuff must be synchronized
with role drop
- pg_shadow and pg_roles need a join to obt
Alvaro Herrera wrote:
> Implementation-side, it requires a new catalog (pg_settings), with the
> following columns:
So, I've come up with the attached patch. It does not have the new
command yet, so you can do ALTER USER and ALTER DATABASE and it works,
but there's no way to set user-and-databas
Hi,
There's a longstanding TODO item, in subject. Previous discussion was
here:
http://archives.postgresql.org/pgsql-hackers/2006-09/msg02341.php
In looking what it would take to implement it, I find that it is
trivial. The only part that looks complex is the UI for it. Is anyone
interested i
41 matches
Mail list logo
