Tom Lane wrote:
> I'm not convinced that it's worth the trouble to make the set of
> reported variables be configurable on-the-fly as Bruce was suggesting.
> client_encoding and datestyle are candidates to send this way, but are
> there really others?
Well, let's look at this from a long term pers
Bruce Momjian <[EMAIL PROTECTED]> writes:
> How about sending an INFO or special taged message to the client when
> there is a GUC change, and have report_changes as a GUC variable that
> controls it?
Having such a variable would break the client libraries that need the
information. They won't st
Bruce Momjian <[EMAIL PROTECTED]> writes:
> How about sending an INFO or special taged message to the client when
> there is a GUC change, and have report_changes as a GUC variable that
> controls it?
just brainstorming. But if you're changing the on-wire representation, perhaps
every transaction
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The question is whether a client-side implementation of autocommit is
> going to allow SET to begin a transaction when autocommit is off.
Well, that'd be up to the client to decide ... but I would imagine
they'd probably make it do so. AFAIR the reason
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, rereading the config file would kill my idea --- but what API are
> > we going to pass SET to applications?
>
> Passing the info up the client-side stack is an issue, yes, but it will
> be so in any case. If it's not there in th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, rereading the config file would kill my idea --- but what API are
> we going to pass SET to applications?
Passing the info up the client-side stack is an issue, yes, but it will
be so in any case. If it's not there in the protocol we haven't even
g
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > One idea is for SET to return a command tag that has more information,
> > like we do for INSERT/UPDATE/DELETE. It could return the variable
> > modified and the new value.
>
> But that doesn't solve the problem --- what about begin,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> One idea is for SET to return a command tag that has more information,
> like we do for INSERT/UPDATE/DELETE. It could return the variable
> modified and the new value.
But that doesn't solve the problem --- what about begin, set, rollback?
What about a
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > We can just say, "Don't alter the client encoding behind the back of the
> > driver."
>
> We can perhaps get away with saying that for client_encoding, but what
> of DateStyle? "SET" has been the traditional way to adjust that sin
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> We can just say, "Don't alter the client encoding behind the back of the
> driver."
We can perhaps get away with saying that for client_encoding, but what
of DateStyle? "SET" has been the traditional way to adjust that since
the stone age.
It seems
Tom Lane writes:
> If the JDBC driver needs to do anything different for one encoding than
> another, then it needs to be informed of changes. We can debate what's
> the most appropriate way to keep it informed, but I don't think we can
> just ignore the need to inform it.
We can just say, "Don'
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The silent assumption behind the client_encoding parameter is that you
> must set it to the actual character set encoding used by the client. If
> you lie, the results are unspecified. So if you're in a JDBC application
> and set the client encoding
Tom Lane writes:
> I had originally been thinking of reporting client_encoding as a field
> of some message sent only at backend startup. However, what if we send
> such a message whenever one of the variables it includes changes?
The silent assumption behind the client_encoding parameter is tha
Tom Lane wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think our SET functionality is easy to understand and use. I don't
> > see pushing it into the client as greatly improving things, and could
> > make things worse. If we can't get it right in the backend, how many
On Thu, 2003-03-20 at 13:41, Barry Lind wrote:
> However the proposed FE/BE protocol change to tell the client the
> transaction state would allow the driver to detect this.
>
>
> Of these two limitations the first is more significant since users do
> issue 'commit' statements directly sometim
Tom,
From the jdbc driver perspective I prefer the GUC variable approach,
but either can be used. Each has limitations.
In 7.2 and earlier jdbc code the driver handled the transaction
symantics by adding begin/commit/rollback in appropriate places. And
that code is still in the 7.3 driver to
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > OK, I have a patch to fix this bug. The basic problem is that when a
> > multi-query string is passed to the backend, it is treated as a single
> > transaction _unless_ a transaction or GUC command appears in the string.
> > When they appear, a
OK, I have a patch to fix this bug. The basic problem is that when a
multi-query string is passed to the backend, it is treated as a single
transaction _unless_ a transaction or GUC command appears in the string.
When they appear, a transaction is forced, but the normal transaction
state machine
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> IIRC, the SET does *not* start a transaction,
>
> > Yes but doesn't autocommit-off mode mean that
> > it implicitly begins a transaction in suitable
> > places ? For example, 'set autoco
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> IIRC, the SET does *not* start a transaction,
> Yes but doesn't autocommit-off mode mean that
> it implicitly begins a transaction in suitable
> places ? For example, 'set autocommit to off;
> declare .. cursor ..' works though it neve
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Anyway should 'set autocommit to off;commit' cause
> > a warning or an error in the first place ?
>
> IIRC, the SET does *not* start a transaction,
Yes but doesn't autocommit-off mode mean that
it implic
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Anyway should 'set autocommit to off;commit' cause
> a warning or an error in the first place ?
IIRC, the SET does *not* start a transaction, so the COMMIT should raise
a warning.
I do not believe that eliminating the warning from COMMIT is a good
idea.
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > The simplest way seems to accept COMMIT any time under autocommit
> > off mode.
>
> That's just hiding the most visible symptom. The real problem here is
> that the SELECT is already committed, when it shoul
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> The simplest way seems to accept COMMIT any time under autocommit
> off mode.
That's just hiding the most visible symptom. The real problem here is
that the SELECT is already committed, when it shouldn't be.
regards, tom lane
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > There seems a bad behavior under autocommit off mode.
>
> > 1) psql -c 'set autocommit to off;select 1;commit'
> > causes a WARNING: COMMIT: no transaction in progress
>
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On Thursday 20 February 2003 10:38, Tom Lane wrote:
>> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> There seems a bad behavior under autocommit off mode.
>
> 1) psql -c 'set autocommit to off;select 1;commit'
> causes a WARNING: COMMIT: no transacti
On Thursday 20 February 2003 10:38, Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > There seems a bad behavior under autocommit off mode.
> >
> > 1) psql -c 'set autocommit to off;select 1;commit'
> > causes a WARNING: COMMIT: no transaction in progress
>
> Surely that's a bug: t
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> There seems a bad behavior under autocommit off mode.
> 1) psql -c 'set autocommit to off;select 1;commit'
> causes a WARNING: COMMIT: no transaction in progress
Surely that's a bug: the SELECT ought to start a transaction block.
Barry Lind reported
Hi all,
There seems a bad behavior under autocommit off mode.
1) psql -c 'set autocommit to off;select 1;commit'
causes a WARNING: COMMIT: no transaction in progress
whereas
2) psql -c 'begin;select 1;commit'
causes no error/warning.
Note that the result is the
29 matches
Mail list logo
