Re: Weird prepared stmt behavior

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Weird prepared stmt behavior
Дата
Msg-id 87zn8p1d4h.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Weird prepared stmt behavior  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Ответы Re: Weird prepared stmt behavior
Список pgsql-hackers
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

> I don't see how this collides with the ideas presented so far.  The JDBC
> driver wants the same: they want to prepare some statements and be able
> to use them later in the session.  They don't want to be paying
> attention to which prepares were committed and which ones weren't.

Oh I thought the idea was that the statement would only be available within a
transaction.

You're saying they span transactions but if the transaction rolls back then it
also rolls back the statement "creation".

Off the top of my head that doesn't seem like a problem. Though I wonder how
that meshes with other database's views on the point.

> Then prepare_cached could send a v3 Prepare and assume the statement
> will be available for the rest of the session.

Incidentally I tried to find documentation on the v3 binary prepare/execute
protocol and failed. I think I ended up looking at libpq calls which is too
high level to understand what the protocol is and isn't capable of. I have
some ideas of what the next step could be.

Where should I be looking? Source code would be fine if the wire protocol
isn't in the documentation.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: mingw configure failure workaround
Следующее
От: Greg Stark
Дата:
Сообщение: Re: PostgreSQL pre-fork speedup