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
-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 Freitag, 6.
Bruno Wolff III wrote:
On Thu, Jan 05, 2006 at 11:44:24 -0800,
Josh Berkus josh@agliodbs.com 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
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 good.
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Josh Berkus josh@agliodbs.com 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
Bruce Momjian pgman@candle.pha.pa.us 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
Marko Kreen wrote:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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,
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us wrote:
Marko Kreen wrote:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
Marko Kreen [EMAIL PROTECTED] writes:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
On Fri, Jan 06, 2006 at 19:11:27 +0200,
Marko Kreen [EMAIL PROTECTED] wrote:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
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
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 pgman@candle.pha.pa.us wrote:
Considering there's no currval() without nextval(), what point
is disallowing currval() when user is able to call nextval()?
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
On 1/6/06, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us wrote:
Uh, logically, yes, but practially currval just reads/SELECTs, while
nextval modifies/UPDATEs.
Yeah, thats the mechanics behind it, but the currval()
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 pgman@candle.pha.pa.us wrote:
Considering there's no currval() without nextval(), what point
is disallowing currval() when user is
Hi,
psql's tab completion has the following problem:
If we have the following syntax for example:
SET SESSION AUTHORIZATION user;
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
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
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
UPDATE to
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
enough
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 current
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 Oracle has
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.
I think the original
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
Marko Kreen wrote:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
Josh Berkus josh@agliodbs.com 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
On 1/7/06, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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 weird. Hmm
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: nextval, currval
Bruce Momjian pgman@candle.pha.pa.us 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
I wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Should UPDATE also allow currval()? Your logic below seems to suggest
that.
---
Tom Lane wrote:
I wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Does the standard require USAGE to support currval?
currval
Tom Lane wrote:
I wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
37 matches
Mail list logo
