From: | Barry Lind <blind(at)xythos(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A bad behavior under autocommit off mode |
Date: | 2003-03-21 23:47:47 |
Message-ID: | 3E7BA4A3.6080107@xythos.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Barry Lind <blind(at)xythos(dot)com> writes:
>
>>In the previous email I discusses why autocommit perhaps shouldn't be a
>>GUC parameter. From a jdbc perspective what was said in that email
>>generally applies to client_encoding and datestyle as well.
>
>
> Hmm. I'm not sure that it makes sense for clients to want to change
> client_encoding on the fly, but it's harder to make that claim for
> datestyle. And datestyle has been a SET variable for so long that we
> would get a *lot* of compatibility flak if we took it away.
>
The issues I was raising are more theoretical than practical. The only
reason I was raising them, is that while we are looking at changes to
the FE/BE protocol we should look at all the issues. Good general
purpose mechanisms (like what Tom is suggesting below) can be created
when a better understanding of all the issues is known.
--Barry
> 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?
> (This is basically Bruce's idea from last night, but refined to only
> send the data when it changes, rather than on every query; that should
> eliminate the bandwidth-wastage objection.)
>
> 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?
>
> A point that would have to be considered is what to do when a SET
> operation is rolled back by transaction abort. I think what we'd need
> to do is retransmit each time the effective value changes; so it'd
> work like this:
>
> -- initial DateStyle is foo
> BEGIN;
> SET DateStyle TO bar;
> -- backend sends status message showing DateStyle = bar
> SELECT ...
> -- reported dates will use DateStyle bar
> ROLLBACK;
> -- backend sends status message showing DateStyle = foo
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2003-03-22 00:14:30 | conversion problems with domains |
Previous Message | Josh Berkus | 2003-03-21 23:32:11 | to_char(interval) --- done? |