Re: SQL-Invoked Procedures for 8.1

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

In response to

Responses

Browse pgsql-hackers by date

  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