Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > True, but GUC seems like the way to go, and we have per-user/db settings
> > for GUC.
>
> But the required autocommit setting depends neither on the user nor the
> database, it depends on the identity of the client application. That type
> of
Bruce Momjian writes:
> True, but GUC seems like the way to go, and we have per-user/db settings
> for GUC.
But the required autocommit setting depends neither on the user nor the
database, it depends on the identity of the client application. That type
of granularity is not offered by GUC.
--
Alvaro Herrera wrote:
> On Tue, Mar 18, 2003 at 05:18:02PM -0500, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > Bruce Momjian writes:
> > >
> > > > What if folks want all their connections autocommit off.
> > >
> > > For interactive use, people can record their preferred setting in
> > >
On Mon, 2003-03-17 at 20:48, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > If we do this, could we get rid of the messy autocommit GUC option and
> > handle autocommit in the client?
>
> Hmm ... that's a thought ... not very backwards-compatible with 7.3,
> but I think I like
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> * Backend's ReadyForQuery message (Z message) should carry an indication
>> of current transaction status (idle/in transaction/in aborted transaction)
>> so that frontend need not guess at state. Perhaps also indicate
>> autocommit
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > * Backend's ReadyForQuery message (Z message) should carry an indication
> > of current transaction status (idle/in transaction/in aborted transaction)
> > so that frontend need not guess at state. Perhaps also indicate
> > autocommit status.
>
>
Tom Lane writes:
> * Backend's ReadyForQuery message (Z message) should carry an indication
> of current transaction status (idle/in transaction/in aborted transaction)
> so that frontend need not guess at state. Perhaps also indicate
> autocommit status.
If we do this, could we get rid of the m
Greg Stark kirjutas K, 12.03.2003 kell 07:10:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>
> > Personally ... as long as a v8.x client can talk to a v7.x backend, you
> > have my vote ... I'm more apt to upgrade my clients before my servers
> > anyway ...
>
> Surely that's not true for a pr
Greg Stark <[EMAIL PROTECTED]> writes:
> It's upgrading the database that's likely to be the driving motivation
> for new sql or storage features. People usually don't get excited
> about upgrading the client libraries :)
Usually not. This cycle might be different though, if we are able to
finish
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Personally ... as long as a v8.x client can talk to a v7.x backend, you
> have my vote ... I'm more apt to upgrade my clients before my servers
> anyway ...
Surely that's not true for a production environment. You have one database but
potentially
On Tue, 11 Mar 2003, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Mon, 10 Mar 2003, Tom Lane wrote:
> >
> > > One of the $64 questions that has to be answered is how much work we're
> > > willing to expend on backwards compatibility. The path of least
> > > resistance would be to handle
On Mon, 10 Mar 2003, Tom Lane wrote:
> One of the $64 questions that has to be answered is how much work we're
> willing to expend on backwards compatibility. The path of least
> resistance would be to handle it the same way we've done protocol
> revisions in the past: the backend will be able to
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> The general idea was to make a framework there to make it easier to add
> something like that in the future. Something that came up when adding
> the SSL negotiation - since that was very kludgy to do with the current
> protocol. But again, if you for
> > X and Y? Well, the first thing that comes to mind is SSL
> support. I'm
> > not sure if it's still that way, but at least it used to be
> a pretty
> > ugly kludge there with the connection being dropped and
> re-connected
> > in some cases.
>
> SSL support is a bad example, since it woul
On Tue, 2003-03-11 at 09:18, Merlin Moncure wrote:
> > If the backend can not handle the version I request, but can handle a
> > prior version, I'd like to know. I am planning on having handlers for
> > multiple protocol versions in the same memory space (I'm using
> > Smalltalk, BTW) so that one
> If the backend can not handle the version I request, but can handle a
> prior version, I'd like to know. I am planning on having handlers for
> multiple protocol versions in the same memory space (I'm using
> Smalltalk, BTW) so that one application can talk to various databases
of
> various vint
Bruce Badger <[EMAIL PROTECTED]> writes:
> I suppose that the client can just keep retrying the connection with
> different versions until it gets a match, though.
Right now, the backend just barfs with
FATAL: unsupported frontend protocol
so you have to do a blind search to see what it wi
On Tue, 2003-03-11 at 06:52, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> >> We already have that: you send a startup packet with a version less than
> >> the latest, and the backend speaks that version to you.
>
> > Yes, but that requires you know the backend is less than the latest
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> X and Y? Well, the first thing that comes to mind is SSL support. I'm
> not sure if it's still that way, but at least it used to be a pretty
> ugly kludge there with the connection being dropped and re-connected in
> some cases.
SSL support is a bad
> * Backend should pass its version number, database encoding,
> default client encoding, and possibly other data (any ideas?) to
> frontend during startup, to avoid need for explicit queries to get
> this info. We could also consider eliminating SET commands sent by
> libpq in favor of adding va
20 matches
Mail list logo
