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:
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 stop
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
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 since
the stone
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
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, set,
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
got
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 the
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 we
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't
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 to me
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 that
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 to an
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.
snip
Of these two limitations the first is more significant since users do
issue 'commit' statements directly
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
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
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
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
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
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: the SELECT
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 transaction in
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 shouldn't be.
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 never
work
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 autocommit to off;
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:
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 implicitly
-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
Surely
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
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
29 matches
Mail list logo
