From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL-Invoked Procedures for 8.1 |
Date: | 2004-09-23 21:42:02 |
Message-ID: | 87y8j0acid.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> In fact it would more or less have to start in a transaction; keep in
> mind that *we cannot do any database access* outside a transaction,
> and therefore we could not have looked up the procedure in the system
> catalogs in the first place without starting a transaction. We could
> however commit that and let the procedure launch its own transactions
> (compare to VACUUM, db-wide CLUSTER, etc) once we have read the
> procedure body from the catalogs and done any pre-parsing we want to do.
Well I guess I'm wondering whether there's any need to commit at all.
If you do commit then you wouldn't be able to do something like:
CREATE PROCEDURE terminate_transaction()
COMMIT;
END PROCEDURE
Admittedly I can't imagine why I would want to do this. But the reference
earlier about being able to declare procedures to be in the same savepoint
namespace as their caller makes me think this is what the spec has in mind.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-23 21:47:52 | Re: SQL-Invoked Procedures for 8.1 |
Previous Message | Tom Lane | 2004-09-23 21:37:04 | Re: SQL-Invoked Procedures for 8.1 |