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 ...  (Hans-Jürgen Schönig <postgres@cybertec.at>)
Re: Implementing RESET CONNECTION ...  (Oliver Jowett <oliver@opencloud.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Bgwriter behavior
Следующее
От: Mark Kirkwood
Дата:
Сообщение: Re: Another Plpgsql trigger example - summary table