Re: Implementing RESET CONNECTION ...
От | Karel Zak |
---|---|
Тема | Re: Implementing RESET CONNECTION ... |
Дата | |
Msg-id | 1104826120.3597.24.camel@petra обсуждение исходный текст |
Ответ на | Re: Implementing RESET CONNECTION ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Implementing RESET CONNECTION ...
Re: Implementing RESET CONNECTION ... |
Список | pgsql-patches |
On Mon, 2005-01-03 at 20:27 -0500, Tom Lane wrote: > I'm inclined to think that we'd have to add a protocol message that > reports RESET CONNECTION to really answer objections of this type. > That seems to bring the thing into the category of "stuff that forces > a protocol version bump" :-( > > Perhaps RESET CONNECTION should be a protocol-level operation instead > of a SQL command? That would prevent user-level code from causing it > without the driver knowing. I still don't see a big difference between DEALLOCATE and RESET -- both can break the JDBC driver. I'm not sure if we need prevent bad usage of PG tools (JDBC in this case). The DEALLOCATE/RESET usage is under user's full control and everything can be described in docs. I think each PG command returns some status. For example in libpq it's possible check by PQcmdStatus(). I think JDBC can checks this status (by own PQcmdStatus() implementation) and if PG returns string "CONNECTION- RESETED" it can deallocate internal stuff. This solution doesn't require touch the protocol. Karel -- Karel Zak <zakkr@zf.jcu.cz>
В списке pgsql-patches по дате отправления: