Re: SQL-Invoked Procedures for 8.1 - Mailing list pgsql-hackers

From Greg Stark
Subject Re: SQL-Invoked Procedures for 8.1
Date
Msg-id 87y8j0acid.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: SQL-Invoked Procedures for 8.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SQL-Invoked Procedures for 8.1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SQL-Invoked Procedures for 8.1
Next
From: Tom Lane
Date:
Subject: Re: SQL-Invoked Procedures for 8.1