Re: PREPARE and transactions

Поиск
Список
Период
Сортировка
От Greg Sabino Mullane
Тема Re: PREPARE and transactions
Дата
Msg-id 8f5b50723e7c687fcde524254b4af473@biglumber.com
обсуждение исходный текст
Ответ на Re: PREPARE and transactions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 
> It occurs to me that a lot of the problem would go away if we allowed
> DEALLOCATE of a nonexistent statement to not be an error (seems like
> a NOTICE would be be plenty).  Then you could just unconditionally
> DEALLOCATE anything you were about to PREPARE, if you weren't entirely
> sure whether it already existed. 
This might quell some of the complaints, but I am still looking for a
good example of a case where there is a real problem with the current
system. If you're calling a prepared statement, then you must claim
the responsibility for having created it. And tracking which ones you
have already created is simple in your application, regardless of whether
you are the main application or just middleware. If you create it, you
track it. If an error occurs, you can safely re-use that name. The
error should never occur due to a invalid statement name.
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200406252215
-----BEGIN PGP SIGNATURE-----
iD8DBQFA3ODAvJuQZxSWSsgRAun9AKCAy13RU4mJ14J9bihiPVm15kvitACghTKv
GgSrqeg9MRROXEwP+AuLSqM=
=Tq9h
-----END PGP SIGNATURE-----




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

Предыдущее
От: Mike Mascari
Дата:
Сообщение: Re: warning missing
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: [COMMITTERS] pgsql-server: Support renaming of tablespaces, and