Re: PREPARE and transactions

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PREPARE and transactions
Date: 2004-06-26 02:32:43
Message-ID: 8f5b50723e7c687fcde524254b4af473@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)turnstep(dot)com
PGP Key: 0x14964AC8 200406252215
-----BEGIN PGP SIGNATURE-----

iD8DBQFA3ODAvJuQZxSWSsgRAun9AKCAy13RU4mJ14J9bihiPVm15kvitACghTKv
GgSrqeg9MRROXEwP+AuLSqM=
=Tq9h
-----END PGP SIGNATURE-----

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2004-06-26 03:43:54 Re: [Re] Re: PREPARE and transactions
Previous Message Christopher Browne 2004-06-25 22:24:59 Re: xeon processors