Re: Implementing RESET CONNECTION ...

Bruce Momjian wrote:
> Hans-J�rgen Sch�nig wrote:
>
>>I completely agree with Karel. I think it is a bad idea to change the
>>protocol for such a minor feature - i tend to call it overkill.
>>I want to add one point to this discussion: There is not just JDBC -
>>other connection pools or clients might want different behaviour (which
>>can from my point of view only lead to a complete reset).
>>
>>If the JDBC driver prefers different behaviour (maybe for prepared
>>statements) we should discuss further options for RESET.
>>Now there is: RESET CONNECTION (cleaning entire connection), RESET ALL
>>(cleaning GUCS only) and RESET some_guc.
>>Maybe we want RESET LISTENER, RESET PREPARED, RESET CURSORS.
>>Personally I think this is not a good idea.
>
>
> I think autocommit is a good example for comparison. One big problem
> was that some users had autocommit in their server configs on startup
> and that caused scripts to fail. I don't imagine anyone would add RESET
> CONNECTION in their startup script.
>
> However, I can imagine someone doing RESET CONNECTION from JDBC and the
> interface should continue working. Should we add something like SET
> CONNECTION that would set the reset values for RESET CONNECTION? JDBC
> could then use SET CONNECTION and then any RESET CONNECTION would reset
> back to that point. RESET has a similar capability where when you RESET
> you reset to the connection defaults, not to the defaults from
> postgresql.conf.
>
> Also, let me mention PHP uses connection pooling and wants to use RESET
> CONNECTION too.
>

Shouldn't these be default values set in postgresql.conf rather than
copied settings inside the backend?

There is always a way to modify a GUC or to change the SET CONNECTION
value (maybe a SELECT statement "SELECT change_value"). I have seen
people doing that millions of time (I know, it is a bad idea).

Personally I'd expect a fully cleanup backend rather than a half-cleaned
up backend. Setting two or three parameters when JDBC provides a
recycled connection should not be a problem.

As far as prepared plans are concerned: There used to be a discussion
about storing prepared plans accross connections (I recall even seeing
some working code by Joe doing exactly that). It was rejected due to
issues related to plan stability. This is exactly the same scenario now
- keeping prepared plans actually means storing them accross "connection
boundaries" (from a logical point of view it is a new connection - even
is the backend is an old one).

If we want the behaviour proposed by JDBC we shouldn't call it RESET
CONNECTION - maybe RESET STATUS or something like that). To me it is a
totally different thing.

Best regards,

Hans

--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/660/816 40 77
www.cybertec.at, www.postgresql.at