On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 06:11 pm, Stephan Szabo wrote:
>
> > I again am not sure I understand, are you saying that under serializable
> > select should start a transaction but it shouldn't under read committed?
> > That seems like a bad idea to me, either
On Wednesday 11 September 2002 06:11 pm, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 02:55 pm, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > If decision (transaction or not) is after parser (before execute)
> > > > this isn't pr
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 02:55 pm, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > >
> > > If decision (transaction or not) is after parser (before execute) this
> > > isn't problem.
> > > I don't know when postgresql make decision, but that
On Wednesday 11 September 2002 02:55 pm, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 03:14 am, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > > > On Wed, 11 Sep 2
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 02:38 pm, Rod Taylor wrote:
> > > > > Why rollback.This is error (typing error).Nothing happen.
> > > > > I think that we need clear set : what is start transaction ?
> > > > > I think that transaction start with change data in da
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 03:14 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > > On Wed, 11 Sep 2002, snpe wrote:
> > > > > yes, we're going around in circles.
> > > >
On Wednesday 11 September 2002 02:38 pm, Rod Taylor wrote:
> > > > Why rollback.This is error (typing error).Nothing happen.
> > > > I think that we need clear set : what is start transaction ?
> > > > I think that transaction start with change data in database
> > > > (what don't change data this
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 04:58 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > > On Wed, 11 Sep 2002, snpe wrote:
> > > > > yes, we're going around in circles.
> > > >
On Wednesday 11 September 2002 03:14 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > yes, we're going around in circles.
> > > >
> > > > Ok.I agreed (I think because Oracle
> > > Why rollback.This is error (typing error).Nothing happen.
> > > I think that we need clear set : what is start transaction ?
> > > I think that transaction start with change data in database
> > > (what don't change data this start not transaction.
> >
> > Another interesting case for a sel
On Wednesday 11 September 2002 04:58 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > yes, we're going around in circles.
> > > >
> > > > Ok.I agreed (I think because Oracle
On Tue, 10 Sep 2002, Barry Lind wrote:
> Yes I can check the server version on connect. In fact that is what the
> driver already does. However I can't check the version and then based
> on the version call set autocommit true in one round trip to the server.
> Since many people don't use c
Curt,
Yes I can check the server version on connect. In fact that is what the
driver already does. However I can't check the version and then based
on the version call set autocommit true in one round trip to the server.
Since many people don't use connection pools, I am reluctant to add
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > yes, we're going around in circles.
> > >
> > > Ok.I agreed (I think because Oracle do different)
> > > Transaction start
> > > I type invalid command
> > >
On Tue, 2002-09-10 at 21:44, Curt Sampson wrote:
> But there were some issues with rolling back and SET commands,
> weren't there? I remember a long discussion about this that I'm
> not sure I want to go back to. :-)
So.. Unless explicitly requested, a SET command should have immediate
effect?
Curt Sampson wrote:
> On Tue, 10 Sep 2002, Bruce Momjian wrote:
>
> > Do we want to say "With autocommit off, SET will be in it's own
> > transaction if it appears before any non-SET command", and "SETs are
> > rolled back except if autocommit off and they appear before any
> > non-SET"?
>
> Not
On Tue, 10 Sep 2002, Bruce Momjian wrote:
> Do we want to say "With autocommit off, SET will be in it's own
> transaction if it appears before any non-SET command", and "SETs are
> rolled back except if autocommit off and they appear before any
> non-SET"?
Not really, I don't think.
But I'm sta
On Tue, 10 Sep 2002, Barry Lind wrote:
> I am waiting for this thread to conclude before deciding exactly what to
> do for the jdbc driver for 7.3. While using the 'set autocommit true'
> syntax is nice when talking to a 7.3 server, the jdbc driver also needs
> to be backwardly compatible with 7
On Tue, 10 Sep 2002, Tom Lane wrote:
> As of CVS tip, SET commands *do* initiate transactions
> if you have autocommit off. By your reading of Date, this is not
> spec compliant for certain SET variables: a SET not already within
> a transaction should not start a transaction block, at least for
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > yes, we're going around in circles.
> > >
> > > Ok.I agreed (I think because Oracle do different)
> > > Transaction start
> > > I type invalid command
> > >
On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > yes, we're going around in circles.
> >
> > Ok.I agreed (I think because Oracle do different)
> > Transaction start
> > I type invalid command
> > I correct command
> > I get error
> >
> > Why.If i
On Wed, 11 Sep 2002, snpe wrote:
> yes, we're going around in circles.
>
> Ok.I agreed (I think because Oracle do different)
> Transaction start
> I type invalid command
> I correct command
> I get error
>
> Why.If is it transactin, why I get error
> I want continue.
> I am see this error with JD
On Wednesday 11 September 2002 01:25 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Tuesday 10 September 2002 11:50 pm, Stephan Szabo wrote:
> > > On Tue, 10 Sep 2002, snpe wrote:
> > > > On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > > > > What if it's a selec
On Wed, 11 Sep 2002, snpe wrote:
> On Tuesday 10 September 2002 11:50 pm, Stephan Szabo wrote:
> > On Tue, 10 Sep 2002, snpe wrote:
> > > On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > > > What if it's a select for update? IF that failed because of a timout
> > > > on a lock, sh
On Tuesday 10 September 2002 11:50 pm, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, snpe wrote:
> > On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > > What if it's a select for update? IF that failed because of a timout
> > > on a lock, shouldn't the transaction fail? Or a select i
On Tue, 10 Sep 2002, snpe wrote:
> On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > What if it's a select for update? IF that failed because of a timout on a
> > lock, shouldn't the transaction fail? Or a select into? Either of those
> > should make a transaction fail, and they
On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> On Tue, 10 Sep 2002, Stephan Szabo wrote:
> > > > > > It starts a transaction, failes the first command and goes into
> > > > > > the error has occurred in this transaction state. Seems like
> > > > > > reasonable behavior.
> > > > >
>
On Tuesday 10 September 2002 09:55 pm, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > That seems messy. What you are saying is that if autocommit is off,
> > then in:
> >
> > SET x=1;
> > UPDATE ...
> > SET y=2;
> > ROLLBACK;
> >
> > that the x=1 doesn't get rolle
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > That seems messy. What you are saying is that if autocommit is off,
> > then in:
>
> > SET x=1;
> > UPDATE ...
> > SET y=2;
> > ROLLBACK;
>
> > that the x=1 doesn't get rolled back bu the y=2 does?
>
> Yes, if you
On Tue, 10 Sep 2002, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, scott.marlowe wrote:
>
> > On Tue, 10 Sep 2002, Stephan Szabo wrote:
> >
> > > > > > > It starts a transaction, failes the first command and goes into the
> > > > > > > error has occurred in this transaction state. Seems like reas
Bruce Momjian <[EMAIL PROTECTED]> writes:
> That seems messy. What you are saying is that if autocommit is off,
> then in:
> SET x=1;
> UPDATE ...
> SET y=2;
> ROLLBACK;
> that the x=1 doesn't get rolled back bu the y=2 does?
Yes, if you weren't in a transaction at the
On Tue, 10 Sep 2002, scott.marlowe wrote:
> On Tue, 10 Sep 2002, Stephan Szabo wrote:
>
> > > > > > It starts a transaction, failes the first command and goes into the
> > > > > > error has occurred in this transaction state. Seems like reasonable
> > > > > > behavior.
> > > > >
> > > > > Select
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Does anyone see any cases where it's important for SET to start
> >> a transaction? (Of course, if you are already *in* a transaction,
> >> the SET will be part of that transaction. The question is whether
> >>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Does anyone see any cases where it's important for SET to start
>> a transaction? (Of course, if you are already *in* a transaction,
>> the SET will be part of that transaction. The question is whether
>> we want SET to trigger an im
On Tue, 10 Sep 2002, Stephan Szabo wrote:
> > > > > It starts a transaction, failes the first command and goes into the
> > > > > error has occurred in this transaction state. Seems like reasonable
> > > > > behavior.
> > > >
> > > > Select command don't start transaction - it is not good
> > >
Tom Lane wrote:
> An example of how this would simplify life: consider the problem of
> a client that wants to ensure autocommit is on. A simple
> SET autocommit TO on;
> doesn't work at the moment: if autocommit is off, then you'll need
> to issue a COMMIT as well to get out of the implici
I am waiting for this thread to conclude before deciding exactly what to
do for the jdbc driver for 7.3. While using the 'set autocommit true'
syntax is nice when talking to a 7.3 server, the jdbc driver also needs
to be backwardly compatible with 7.2 and 7.1 servers. So it may just be
easier to
> > > > It starts a transaction, failes the first command and goes into the
> > > > error has occurred in this transaction state. Seems like reasonable
> > > > behavior.
> > >
> > > Select command don't start transaction - it is not good
> >
> > I think you need more justification than "it is not
Curt Sampson <[EMAIL PROTECTED]> writes:
> From Date's _A Guide to the SQL Standard_ (Fourth Edition):
> ...
> The following SQL statements are _not_ transaction-initiating:
> CONNECT
> SET CONNECTION
> DISCONNECT
> SET SESSION AUTHORIZATION
> SET CATALOG
>
On Tuesday 10 September 2002 04:16 am, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, snpe wrote:
> > On Tuesday 10 September 2002 03:05 am, Stephan Szabo wrote:
> > > On Tue, 10 Sep 2002, snpe wrote:
> > > > On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > > > > On Mon, 2002-09-09 at 17:0
ruce Momjian
> Cc: Barry Lind; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [JDBC] [HACKERS] problem with new autocommit config
> parameter and jdbc
>
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Barry Lind wrote:
> >> How should client in
Curt Sampson <[EMAIL PROTECTED]> writes:
> Probably the driver should be changed for 7.3 just to use the server's
> SET AUTOCOMMIT functionality
That should happen eventually, IMHO, but I am not going to tell the JDBC
developers that they must make it happen for 7.3. They've already got a
pi
On Mon, 9 Sep 2002, Tom Lane wrote:
> If autocommit=off really seriously breaks JDBC then I don't think a
> simple SET command at the start of a session is going to do that much
> to improve robustness. What if the user issues another SET to turn it
> on?
You mean, to turn it off again? The dri
On Mon, 9 Sep 2002, Tom Lane wrote:
> snpe <[EMAIL PROTECTED]> writes:
>
> > snpe> select * from org_ba;
> > ERROR: relation org_ba does not exists
> > snpe> select * from org_ban;
> > ERROR: current transactions is aborted, queries ignored until end of
> > transaction block
>
> Um, what's wrong
snpe <[EMAIL PROTECTED]> writes:
> I'm use 'autocommit=false' and have problem with psql
> When any commnad is lost, then next commnad get error for transactions
> (simple select command).BTW
> snpe> select * from org_ba;
> ERROR: relation org_ba does not exists
> snpe> select * from org_ban;
> E
On Tue, 10 Sep 2002, snpe wrote:
> On Tuesday 10 September 2002 03:05 am, Stephan Szabo wrote:
> > On Tue, 10 Sep 2002, snpe wrote:
> > > On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > > > On Mon, 2002-09-09 at 17:04, snpe wrote:
> > > > > I'm use 'autocommit=false' and have problem
On Tuesday 10 September 2002 03:05 am, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, snpe wrote:
> > On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > > On Mon, 2002-09-09 at 17:04, snpe wrote:
> > > > I'm use 'autocommit=false' and have problem with psql
> > > > When any commnad is lost,
On Tue, 10 Sep 2002, snpe wrote:
> On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > On Mon, 2002-09-09 at 17:04, snpe wrote:
> > > I'm use 'autocommit=false' and have problem with psql
> > > When any commnad is lost, then next commnad get error for transactions
> > > (simple select co
On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> On Mon, 2002-09-09 at 17:04, snpe wrote:
> > I'm use 'autocommit=false' and have problem with psql
> > When any commnad is lost, then next commnad get error for transactions
> > (simple select command).BTW
> >
> > snpe> select * from org_ba
On Mon, 2002-09-09 at 17:04, snpe wrote:
> I'm use 'autocommit=false' and have problem with psql
> When any commnad is lost, then next commnad get error for transactions
> (simple select command).BTW
>
> snpe> select * from org_ba;
> ERROR: relation org_ba does not exists
> snpe> select * from o
On Monday 09 September 2002 08:53 pm, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Barry Lind wrote:
> >> How should client interfaces handle this new autocommit feature? Is it
> >> best to just issue a set at the beginning of the connection to ensure
> >> that it is always on?
t; Sincerely,
>
> Daryl.
>
>
>
>>-Original Message-
>>From: Tom Lane [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, September 09, 2002 2:54 PM
>>To: Bruce Momjian
>>Cc: Barry Lind; [EMAIL PROTECTED];
>>[EMAIL PROTECTED]
>>Subject: Re:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Barry Lind wrote:
>> How should client interfaces handle this new autocommit feature? Is it
>> best to just issue a set at the beginning of the connection to ensure
>> that it is always on?
> Yes, I thought that was the best fix for apps that can't dea
Yes it is possible, but according to the jdbc spec, a new connection in
jdbc is always initialized to autocommit=true. So jdbc needs to ignore
whatever the current server setting is and reset to autocommit=true.
--Barry
snpe wrote:
> On Saturday 07 September 2002 02:55 am, Bruce Momjian wrote
snpe wrote:
> On Saturday 07 September 2002 02:55 am, Bruce Momjian wrote:
> > Barry Lind wrote:
> > > Haris,
> > >
> > > You can't use jdbc (and probably most other postgres clients) with
> > > autocommit in postgresql.conf turned off.
> > >
> > > Hackers,
> > >
> > > How should client interfaces
On Saturday 07 September 2002 02:55 am, Bruce Momjian wrote:
> Barry Lind wrote:
> > Haris,
> >
> > You can't use jdbc (and probably most other postgres clients) with
> > autocommit in postgresql.conf turned off.
> >
> > Hackers,
> >
> > How should client interfaces handle this new autocommit feat
Barry Lind wrote:
> Haris,
>
> You can't use jdbc (and probably most other postgres clients) with
> autocommit in postgresql.conf turned off.
>
> Hackers,
>
> How should client interfaces handle this new autocommit feature? Is it
> best to just issue a set at the beginning of the connection to
Haris,
You can't use jdbc (and probably most other postgres clients) with
autocommit in postgresql.conf turned off.
Hackers,
How should client interfaces handle this new autocommit feature? Is it
best to just issue a set at the beginning of the connection to ensure
that it is always on?
thank
Hello Barry,
JDBC driver must find autocommit (off or on) and set autoCommit field
when open connection.
regards
On Friday 06 September 2002 06:52 pm, Barry Lind wrote:
> Haris,
>
> You can't use jdbc (and probably most other postgres clients) with
> autocommit in postgresql.conf turned off.
>
>
I believe that
SELECT EXTRACT(EPOCH FROM TIMESTAMP '2001-02-16 20:38:40');
ahould give a fairly large integer --- in 7.2 I get 982373920.
But CVS tip (without the int64-timestamp option) produces
982.35592. Broken, no?
regards, tom lane
---(end of
, 2002 3:41 PM
To: '[EMAIL PROTECTED]'
Subject: [HACKERS] Problem with lower() function
Hi, We have a problem with lower() function working differently for two
different data types
table: yuva_test
column_name data_type
yt_name1varchar(255)
yt_name2char(1)
The data i
Hi, We have a problem with lower() function working differently for two
different data types
table: yuva_test
column_name data_type
yt_name1varchar(255)
yt_name2char(1)
The data is
yt_name1yt_name2
yuvaF
bharat F
1234556 F
234 F
etc.
Bear, there is some IPv6 stuff in fe-secure.c. Is this intended? We
don't support IPv6 in the backend yet, do we. We are having portability
problems with that 'case' statement and I am considering removing it.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTE
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> ERROR: Unrecognized language specified in a CREATE FUNCTION: 'plpgsql'.
> Pre-installed languages are SQL, C, and internal.
> Additional languages may be installed using 'createlang'.
> I've done a "createlang plpgsql templa
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
[snap]
> How do I get this to work?
>
> Chris
I think i did this:
CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS
'/usr/local/pgsql/lib/plpgsql.so', 'plpgsql_call_handler' LANGUAGE 'C';
CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' H
Hi all,
I'm having problems restoring a dump. I get this:
You are now connected as new user chriskl.
ERROR: Unrecognized language specified in a CREATE FUNCTION: 'plpgsql'.
Pre-installed languages are SQL, C, and internal.
Additional languages may be installed using 'createlang
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Bruce Momjian wrote:
> I see in quote.c::do_quote_ident():
>
>*cp2++ = '"';
>while (len-- > 0)
>{
> if (*cp1 == '"')
> *cp2++ = '"';
> if (*cp1 == '\\')
> *cp2++ = '\\';
> *cp2++ = *cp1++;
>}
>*cp2++ = '"';
>
> I am confused by
I see in quote.c::do_quote_ident():
*cp2++ = '"';
while (len-- > 0)
{
if (*cp1 == '"')
*cp2++ = '"';
if (*cp1 == '\\')
*cp2++ = '\\';
*cp2++ = *cp1++;
}
*cp2++ =
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > I don't think GRANT CONNECT fits into our setup at all. I also doubt
> > that it will be needed very much once we have schemas.
>
> People have many times asked for a way to alter the connection settings
> from within the database. For instance,
[EMAIL PROTECTED] ("Luis Alberto Amigo Navarro") wrote in message
news:<005901c1d17a$4d7b0e10$[EMAIL PROTECTED]>...
> >
> > cc-1070 cc: ERROR File = xact.c, Line = 587
> > The indicated type is incomplete.
> >
> > struct timeval delay;
>
> struct timeval must be defined
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I don't know. Automatically modifying a manually maintained config file
> > isn't too common a feature. One problem would be if you where modifying
> > the file in your editor and the backend rewrote the file.
>
> That's not different from
Bruce Momjian writes:
> I don't know. Automatically modifying a manually maintained config file
> isn't too common a feature. One problem would be if you where modifying
> the file in your editor and the backend rewrote the file.
That's not different from you modifying the file in your editor
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > I don't think GRANT CONNECT fits into our setup at all. I also doubt
> > that it will be needed very much once we have schemas.
>
> People have many times asked for a way to alter the connection settings
> from within the database. For instance,
Tom Lane writes:
> I don't think GRANT CONNECT fits into our setup at all. I also doubt
> that it will be needed very much once we have schemas.
People have many times asked for a way to alter the connection settings
from within the database. For instance, you add users in the database,
but th
>
> cc-1070 cc: ERROR File = xact.c, Line = 587
> The indicated type is incomplete.
>
> struct timeval delay;
struct timeval must be defined on your "include path"/sys/time.h, what have
you got?
regards
---(end of broadcast)-
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Unfortunately, that would give us two places to specify
> > the connecting users, pg_hba.conf and GRANT CONNECT. Is that a problem?
>
> Yes. What if they conflict?
>
> I don't think GRANT CONNECT fits into our setup at all. I als
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Unfortunately, that would give us two places to specify
> the connecting users, pg_hba.conf and GRANT CONNECT. Is that a problem?
Yes. What if they conflict?
I don't think GRANT CONNECT fits into our setup at all. I also doubt
that it will be needed
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I have another idea. What if we had a default group for each database,
> > like pg_connect_{dbname}, and you can add/remove users from that group
> > to grant/remove connection privileges?
>
> That strikes me as a very ugly abuse of the priv
Bruce Momjian writes:
> I have another idea. What if we had a default group for each database,
> like pg_connect_{dbname}, and you can add/remove users from that group
> to grant/remove connection privileges?
That strikes me as a very ugly abuse of the privilege system. If you want
to grant a
pgman wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > I am adding users and groups to pg_hba.conf.
> >
> > You know what would be cool?
> >
> > GRANT CONNECT ON mydb TO GROUP myfriends;
> >
> > and it rewrites pg_hba.conf accordingly.
> >
> > Just a thought...
>
> We are
Bruce Momjian wrote:
>
> Now, as far as rewriting pg_hba.conf, that goes into an area where we
> are not sure if the master connection information is in the file or in
> the database. We also get into a chicken and egg case where we have to
> have the database loaded to connect to it. I am inte
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I am adding users and groups to pg_hba.conf.
>
> You know what would be cool?
>
> GRANT CONNECT ON mydb TO GROUP myfriends;
>
> and it rewrites pg_hba.conf accordingly.
>
> Just a thought...
We are actually not that far away. If you crea
Bruce Momjian writes:
> I am adding users and groups to pg_hba.conf.
You know what would be cool?
GRANT CONNECT ON mydb TO GROUP myfriends;
and it rewrites pg_hba.conf accordingly.
Just a thought...
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)-
I've been able to compile previous versions of PostgreSQL on my SGI
machines, but am having trouble this time. I have an SGI O2 with IRIX
6.5.15f, gmake 3.79.1, and MIPSPro C 7.3.1.3 compiler. I can get
through the 'configure' step fine. I've copied the Makefile.irix5 up
to the src directory. I've
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The problem is when to retokenize pg_hba.conf after a new pg_group is
> > made. Seems I can either force administrators to 'pg_ctl reload' to
> > update for group changes, or automatically retokenize pg_hba.conf every
> > time I upda
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, that was the issue. We tell people pg_hba.conf only gets reloaded
> > when they tell the postmaster to do it. We can't have it happening at
> > random times, e.g. password change.
>
> I agree on that: the signal should cause t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, that was the issue. We tell people pg_hba.conf only gets reloaded
> when they tell the postmaster to do it. We can't have it happening at
> random times, e.g. password change.
I agree on that: the signal should cause the postmaster to reload
pg_p
Ross J. Reedstrom wrote:
> On Thu, Mar 21, 2002 at 11:38:05AM -0500, Bruce Momjian wrote:
> >
> > I am handling it like pg_shadow. The problem is that because I expand
> > pg_group inside the pg_hba tokens, I have to retokenize pg_hba.conf too
> > after pg_group changes. I assumed we didn't want
I think I have figured out a way to do this efficiently. Instead of
making pg_group with groupname/username on each line, I will do
groupname/username,username, ... so I can spin through the group token
file much quicker; that way, I can read just retokenize pg_group and
spin through it for eac
On Wed, 10 Oct 2001, Dmitry Chernikov wrote:
> Hello,
>
> In dump file statement which grants permissions on view exists before
> statement which create view.
> For tables and sequences permissions dumped in correct order.
>
> --TOC Entry ID 124 (OID 150248)
> GRANT ALL on my_view to group sales;
Hello,
In dump file statement which grants permissions on view exists before
statement which create view.
For tables and sequences permissions dumped in correct order.
--TOC Entry ID 124 (OID 150248)
GRANT ALL on my_view to group sales;
... skipped
--TOC Entry ID 123 (OID 194103)
CREATE VIEW m
Ilya,
check your system locale - does simple perl script works properly
Oleg
On Tue, 9 Oct 2001, Korshunov Ilya wrote:
> Hello!
> I have a trouble with PostgreSQL 7.1.3 (and 7.1.2 too). My OS is Solaris 8x86 with
>russian locale. PostgreSQL was builded from sources and configured with
Hello!
I have a trouble with PostgreSQL 7.1.3 (and
7.1.2 too). My OS is Solaris 8x86 with russian locale. PostgreSQL was builded
from sources and configured with : --enable-locale --enable-multibyte=WIN.
My problem with sorting lowercase russian
words in the text fields (type - "varchar"
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> Of course the working source is 3rd October.
> Tom, do you have an idea what you might have fixed to that effect ?
No idea. I've been fixing some portability issues in dynahash.c,
but AFAIK they only affected the pgstats collector proce
>
> > > I am quite sure that all AIX Versions accept the CLOBBER method,
> > > thus I ask you to apply the following patch, to make it work.
> >
> > CLOBBER does not work with AIX5L, nor CHANGE_ARGV. (SETPROCTITLE,
> > PSTAT and PS_STRINGS can not be used since AIX5L does not have
> > appropreat
> > > BTW, still I'm getting the stucking backends. New info: a snapshot
> > > dated on 10/3 works fine.
> >
> > I allways have trouble with those different date formats. Do you
> > mean, that the problem is fixed as of 3. October, or that an old
> > snapshot from 10. March still worked ?
>
> O
> > BTW, still I'm getting the stucking backends. New info: a snapshot
> > dated on 10/3 works fine.
>
> I allways have trouble with those different date formats. Do you
> mean, that the problem is fixed as of 3. October, or that an old
> snapshot from 10. March still worked ?
Of course the work
> BTW, still I'm getting the stucking backends. New info: a snapshot
> dated on 10/3 works fine.
I allways have trouble with those different date formats. Do you
mean, that the problem is fixed as of 3. October, or that an old
snapshot from 10. March still worked ?
Snapshot of 1. Oct 2001 does
> > > I am quite sure that all AIX Versions accept the CLOBBER method,
> > > thus I ask you to apply the following patch, to make it work.
> >
> > CLOBBER does not work with AIX5L, nor CHANGE_ARGV. (SETPROCTITLE,
> > PSTAT and PS_STRINGS can not be used since AIX5L does not have
> > appropreate h
901 - 1000 of 1070 matches
Mail list logo
