Bruce Momjian writes:
> Should UPDATE also allow currval()? Your logic below seems to suggest
> that.
I thought about that, but there are a couple of reasons not to:
1. It'd be a change from the current behavior of UPDATE privilege.
2. If there's someone out there who really does want write-onl
Tom Lane wrote:
> I wrote:
> > Bruce Momjian writes:
> >> Does the standard require USAGE to support currval?
>
> > currval isn't in the standard (unless I missed something), so it has
> > nothing to say one way or the other on the point.
>
> Wait, I take that back. Remember our previous discus
Should UPDATE also allow currval()? Your logic below seems to suggest
that.
---
Tom Lane wrote:
> I wrote:
> > Bruce Momjian writes:
> >> Does the standard require USAGE to support currval?
>
> > currval isn't in the stan
I wrote:
> Bruce Momjian writes:
>> Does the standard require USAGE to support currval?
> currval isn't in the standard (unless I missed something), so it has
> nothing to say one way or the other on the point.
Wait, I take that back. Remember our previous discussions about this
point: the spec
Bruce Momjian writes:
> Does the standard require USAGE to support currval?
currval isn't in the standard (unless I missed something), so it has
nothing to say one way or the other on the point.
Basically what we seem to be homing in on is to keep SELECT and UPDATE
privileges doing what they do
Tom Lane wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > Good point about compatibility. But makes the common case ugly.
> > "For regular usage you need to grant SELECT, USAGE ..." Huh? :)
>
> > How about this:
>
> > SELECT: currval
> > INSERT: nextval
> > UPDATE: nextval, setval
> > USAGE
Marko Kreen <[EMAIL PROTECTED]> writes:
> Good point about compatibility. But makes the common case ugly.
> "For regular usage you need to grant SELECT, USAGE ..." Huh? :)
> How about this:
> SELECT: currval
> INSERT: nextval
> UPDATE: nextval, setval
> USAGE: nextval, currval
Seems a little w
Marko Kreen wrote:
> On 1/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Bruce Momjian writes:
> > > FYI, we could support USAGE just on sequences, and have it map to
> > > UPDATE, but pg_dump it out as USAGE.
> >
> > It seems the spec doesn't cover setval() and currval(), which is not
> > too surp
On 1/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian writes:
> > FYI, we could support USAGE just on sequences, and have it map to
> > UPDATE, but pg_dump it out as USAGE.
>
> It seems the spec doesn't cover setval() and currval(), which is not
> too surprising given those aren't standar
Josh Berkus writes:
>> BTW, what about lastval()?
> Overal, it's hard to get too concerned about this, since a user can't
> really get anything out of lastval() if he doesn't have permissions on the
> sequence he's trying to query, in order to run currval.
Well, no, consider my example to Mark
Tom,
> BTW, what about lastval()? I'm not sure we can usefully associate any
> privilege check with that, since it's not clear which sequence it
> applies to. Does it make sense to remember what sequence the value came
> from and privilege-check against that, or is that just too weird?
Hmmm. Y
Bruce Momjian writes:
> FYI, we could support USAGE just on sequences, and have it map to
> UPDATE, but pg_dump it out as USAGE.
It seems the spec doesn't cover setval() and currval(), which is not
too surprising given those aren't standard.
Here is a proposal:
SELECT priv -> allows currval() a
Marko Kreen wrote:
> On 1/6/06, Bruce Momjian wrote:
> > Marko Kreen wrote:
> > > I found SQL2003 pdf's too ... from my reading it has only USAGE.
> > >
> > > 5WD-02-Foundation-2003-09.pdf:
> > > page 724 -> General Rules -> #2
> > > page 740 -> Syntax rules -> #3
> >
> > I admit I am terrible at
On 1/6/06, Bruce Momjian wrote:
> Jaime Casanova wrote:
> > On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > > Marko Kreen <[EMAIL PROTECTED]> writes:
> > > > But my question is rather - is there any scenario where setval() should
> > > > go with nextval()?
> > >
> > > > It seems that their pair
On 1/6/06, Bruce Momjian wrote:
> Marko Kreen wrote:
> > I found SQL2003 pdf's too ... from my reading it has only USAGE.
> >
> > 5WD-02-Foundation-2003-09.pdf:
> > page 724 -> General Rules -> #2
> > page 740 -> Syntax rules -> #3
>
> I admit I am terrible at understanding the standard, but I can
Jaime Casanova wrote:
> On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Marko Kreen <[EMAIL PROTECTED]> writes:
> > > But my question is rather - is there any scenario where setval() should
> > > go with nextval()?
> >
> > > It seems that their pairing is an accident and should be fixed.
> >
> >
Marko Kreen wrote:
> > In any case I think we are wasting our time discussing it, and instead
> > should be looking through the SQL2003 spec to see what it requires.
> > Bruce couldn't find anything in it about this but I can't believe the
> > info isn't there somewhere.
>
> Google tells that Orac
On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > But my question is rather - is there any scenario where setval() should
> > go with nextval()?
>
> > It seems that their pairing is an accident and should be fixed.
>
> I think the original argument for the
Tom Lane wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > But my question is rather - is there any scenario where setval() should
> > go with nextval()?
>
> > It seems that their pairing is an accident and should be fixed.
>
> I think the original argument for the current design was that with
Bruce Momjian wrote:
> > I'm not sure offhand what keywords we'd want to use, but now is the time
> > to look at it, *before* it becomes set in stone that GRANT ON SEQUENCE
> > is just another spelling of GRANT ON TABLE.
>
> Sequences do not support INSERT, UPDATE, or DELETE, but we overload
> UPD
Marko Kreen <[EMAIL PROTECTED]> writes:
> But my question is rather - is there any scenario where setval() should
> go with nextval()?
> It seems that their pairing is an accident and should be fixed.
I think the original argument for the current design was that with
enough nextval's you can dupl
Hi,
psql's tab completion has the following problem:
If we have the following syntax for example:
SET SESSION AUTHORIZATION ;
SET SESSION AUTHORIZATION DEFAULT;
After "SET SESSION AUTHORIZATION", the tab completion can offer a list of
roles or the string constant "DEFAULT". However it can't off
On 1/6/06, Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 06, 2006 at 19:11:27 +0200,
> Marko Kreen <[EMAIL PROTECTED]> wrote:
> > On 1/6/06, Bruce Momjian wrote:
> >
> > Considering there's no currval() without nextval(), what point
> > is disallowing currval() when user is able to ca
On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > On 1/6/06, Bruce Momjian wrote:
> >> Uh, logically, yes, but practially currval just reads/SELECTs, while
> >> nextval modifies/UPDATEs.
>
> > Yeah, thats the mechanics behind it, but the currval() only
>
Dear Bruce san.
I think that a certain user has a meaning as for this client construction.
There is a user who demands to build only by Microsoft thoroughly.
However, it may be ignored if support load is disliked. What is necessary
will be just to remain in a mail archive, even if this is not ap
Bruno Wolff III wrote:
> On Fri, Jan 06, 2006 at 19:11:27 +0200,
> Marko Kreen <[EMAIL PROTECTED]> wrote:
> > On 1/6/06, Bruce Momjian wrote:
> >
> > Considering there's no currval() without nextval(), what point
> > is disallowing currval() when user is able to call nextval()?
> >
> > I rathe
From: "Magnus Hagander"
HOMEDIR = "C:/Documents and Settings/saito/Application
Data/postgresql"
VERSION = PostgreSQL 8.1.1
HOMEDIR is a very bad name for this variable, since it's *not* the home
directory. It could easily be confused. If we put it in, I definitly
think it should be called som
On Fri, Jan 06, 2006 at 19:11:27 +0200,
Marko Kreen <[EMAIL PROTECTED]> wrote:
> On 1/6/06, Bruce Momjian wrote:
>
> Considering there's no currval() without nextval(), what point
> is disallowing currval() when user is able to call nextval()?
>
> I rather want to allow nextval/currval and dis
Marko Kreen <[EMAIL PROTECTED]> writes:
> On 1/6/06, Bruce Momjian wrote:
>> Uh, logically, yes, but practially currval just reads/SELECTs, while
>> nextval modifies/UPDATEs.
> Yeah, thats the mechanics behind it, but the currval() only
> works if the user was already able to call nextval(), so I
On 1/6/06, Bruce Momjian wrote:
> Marko Kreen wrote:
> > On 1/6/06, Bruce Momjian wrote:
> > > Bruno Wolff III wrote:
> > > > It might be nice to split nextval and currval access as well. nextval
> > > > access
> > > > corresponds to INSERT and currval access to SELECT.
> > >
> > > Uh, that is a
Tom Lane wrote:
> Bruce Momjian writes:
> > FYI, SQL03 defines GRANT SEQUENCE.
>
> Oh. Well, then that gives us precedent to go by. What do they specify
> as the privileges for sequences?
They don't seem to specify which actions go with which objects in the
GRANT statement, nor do they specify
Marko Kreen wrote:
> On 1/6/06, Bruce Momjian wrote:
> > Bruno Wolff III wrote:
> > > It might be nice to split nextval and currval access as well. nextval
> > > access
> > > corresponds to INSERT and currval access to SELECT.
> >
> > Uh, that is already in the code. nextval()/setval() is UPDATE
Bruce Momjian writes:
> FYI, SQL03 defines GRANT SEQUENCE.
Oh. Well, then that gives us precedent to go by. What do they specify
as the privileges for sequences?
regards, tom lane
---(end of broadcast)---
TIP 9: In versio
Tom Lane wrote:
> Josh Berkus writes:
> >> Uh, how are they different? You mean just UPDATE and none of the
> >> others do anything?
>
> > Yes, it would be nice to have real permissions for sequences, specifically
> > USE (which allows nextval() and currval()) and UPDATE (which would allow
>
On 1/6/06, Bruce Momjian wrote:
> Bruno Wolff III wrote:
> > It might be nice to split nextval and currval access as well. nextval access
> > corresponds to INSERT and currval access to SELECT.
>
> Uh, that is already in the code. nextval()/setval() is UPDATE, and
> currval() is SELECT.
This see
> I receive an inquiry from a user frequently. Where is it
> about a home directory in a place? Then, In offer of the
> initial state of Windows, the place is hidden and is not
> visible to a user. I considered what can be offered this way
> and that. Then, using pg_config thinks that it is goo
Bruno Wolff III wrote:
> On Thu, Jan 05, 2006 at 11:44:24 -0800,
> Josh Berkus wrote:
> > Bruce, Tom,
> >
> > > > The permissions for a sequence aren't the same as they are for a
> > > > table. We've sort of ignored the point to date, but if we're going to
> > > > add special syntax for grantin
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Peter Eisentraut
> Sent: 06 January 2006 11:07
> To: pgsql-patches@postgresql.org
> Cc: Hiroshi Saito
> Subject: Re: [PATCHES] display and expression of the home
> directory in Win32
>
> Am Frei
Am Freitag, 6. Januar 2006 04:03 schrieb Hiroshi Saito:
[pg_config]
> HOMEDIR = "C:/Documents and Settings/saito/Application Data/postgresql"
Where does this come from and what would it be good for?
---(end of broadcast)---
TIP 6: explain analyze is
39 matches
Mail list logo
