"stored procedures"

Hi Peter

2011/4/21 Peter Eisentraut <peter_e@gmx.net>:

So the topic of "real" "stored procedures" came up again.  Meaning a
function-like object that executes outside of a regular transaction,
with the ability to start and stop SQL transactions itself.

I would like to collect some specs on this feature.  So does anyone have
links to documentation of existing implementations, or their own spec
writeup?  A lot of people appear to have a very clear idea of this
concept in their own head, so let's start collecting those.

I had a patch for "transactional" procedures, but this is lost :(

http://okbob.blogspot.com/2007/11/stacked-recordset-multirecordset.html

What I (We) expect:

Very important points:
1. possible explicit transaction controlling - not only subtransactions
2. correct or usual behave of OUT parameters (important for JDBC people)
*** attention: overloading is related to OUT parameters too ***

Not necessary but nice:
3. Support for multirecordset and RETURN_STATUS variable
(RETURN_STATUS is defined by ANSI)

Regards

Pavel

On Thu, Apr 21, 2011 at 11:24 AM, Peter Eisentraut <peter_e@gmx.net> wrote:

So the topic of "real" "stored procedures" came up again.  Meaning a
function-like object that executes outside of a regular transaction,
with the ability to start and stop SQL transactions itself.

I would like to collect some specs on this feature.  So does anyone have
links to documentation of existing implementations, or their own spec
writeup?  A lot of people appear to have a very clear idea of this
concept in their own head, so let's start collecting those.

EDB has an implementation of this in Advanced Server. A stored
procedure can issue a COMMIT, which commits the current transaction
and begins a new one. This might or might not be what people are
imagining for this feature. If we end up doing something else, one
thing to consider is the impact on third-party tools like PGPOOL,
which currently keep track of whether or not a transaction is in
progress by snooping on the stream of SQL commands. If a procedure
can be started with no transaction in progress and return with one
open, or the other way around, that method will break horribly.
That's not necessarily a reason not to do it, but I suspect we would
want to add some kind of protocol-level information about the
transaction state instead so that such tools could continue to work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:

EDB has an implementation of this in Advanced Server. A stored
procedure can issue a COMMIT, which commits the current transaction
and begins a new one. This might or might not be what people are
imagining for this feature. If we end up doing something else, one
thing to consider is the impact on third-party tools like PGPOOL,
which currently keep track of whether or not a transaction is in
progress by snooping on the stream of SQL commands. If a procedure
can be started with no transaction in progress and return with one
open, or the other way around, that method will break horribly.
That's not necessarily a reason not to do it, but I suspect we would
want to add some kind of protocol-level information about the
transaction state instead so that such tools could continue to work.

Huh? There's been a transaction state indicator in the protocol since
7.4 (see ReadyForQuery). It's not our problem if PGPOOL is still using
methods that were appropriate ten years ago.

regards, tom lane

On Thu, Apr 21, 2011 at 12:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

EDB has an implementation of this in Advanced Server.  A stored
procedure can issue a COMMIT, which commits the current transaction
and begins a new one.  This might or might not be what people are
imagining for this feature.  If we end up doing something else, one
thing to consider is the impact on third-party tools like PGPOOL,
which currently keep track of whether or not a transaction is in
progress by snooping on the stream of SQL commands.  If a procedure
can be started with no transaction in progress and return with one
open, or the other way around, that method will break horribly.
That's not necessarily a reason not to do it, but I suspect we would
want to add some kind of protocol-level information about the
transaction state instead so that such tools could continue to work.

Huh?  There's been a transaction state indicator in the protocol since
7.4 (see ReadyForQuery).  It's not our problem if PGPOOL is still using
methods that were appropriate ten years ago.

Hmm. Well, maybe we need some PGPOOL folks to weigh in. Possibly
it's just a case of "it ain't broke, so we haven't fixed it".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Peter,

I would like to collect some specs on this feature. So does anyone have
links to documentation of existing implementations, or their own spec
writeup? A lot of people appear to have a very clear idea of this
concept in their own head, so let's start collecting those.

Delta between SPs and Functions for PostgreSQL:

* SPs are executed using CALL or EXECUTE, and not SELECT.

* SPs do not return a value
** optional: SPs *may* have OUT parameters.

* SPs have internal transactions including begin/commit
** optional: SPs can run non-transaction statements,
like CREATE INDEX CONCURRENTLY and VACUUM
** corollary: SPs may not be called as part of a larger query
** question: if an SP is called by another SP, what is its
transaction context?

* optional: SPs can return multisets (ala SQL Server).
** question: how would multisets be handled on the client end?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

Hello

2011/4/21 Josh Berkus <josh@agliodbs.com>:

Peter,

I would like to collect some specs on this feature.  So does anyone have
links to documentation of existing implementations, or their own spec
writeup?  A lot of people appear to have a very clear idea of this
concept in their own head, so let's start collecting those.

Delta between SPs and Functions for PostgreSQL:

* SPs are executed using CALL or EXECUTE, and not SELECT.

* SPs do not return a value
** optional: SPs *may* have OUT parameters.

SP can returns value - result status or RETURNED_SQLSTATE. Result
status is hidden OUT parameter

* SPs have internal transactions including begin/commit
** optional: SPs can run non-transaction statements,
  like CREATE INDEX CONCURRENTLY and VACUUM
** corollary: SPs may not be called as part of a larger query
** question: if an SP is called by another SP, what is its
  transaction context?

* optional: SPs can return multisets (ala SQL Server).
** question: how would multisets be handled on the client end?

you should to use some "next" function for iteration between resultsets

http://dev.mysql.com/doc/refman/5.0/en/mysql-next-result.html

similar function exists in MSSQL API too

Regards

Pavel Stehule

I'm pretty close to agreement with Josh, I think.

Josh Berkus <josh@agliodbs.com> wrote:

Delta between SPs and Functions for PostgreSQL:

* SPs are executed using CALL or EXECUTE, and not SELECT.

Agreed, although some products will search for a matching procedure
name if the start of a statement doesn't match any reserved word.
That can be handy -- you run them more or less like commands.

* SPs do not return a value

I've used some products where these were available, although in some
cases only setting what in PostgreSQL would be the equivalent of an
integer session GUC.

** optional: SPs *may* have OUT parameters.

Support for those would be important to handle some common uses of
SPs.

* SPs have internal transactions including begin/commit

Yeah. Entering or leaving an SP should not start or end a
transaction. BEGIN, COMMIT, ROLLBACK, and SAVEPOINT should all be
available and should not disrupt statement flow.

** optional: SPs can run non-transaction statements,
like CREATE INDEX CONCURRENTLY and VACUUM

That seems important.

** corollary: SPs may not be called as part of a larger query

OK.

** question: if an SP is called by another SP, what is its
transaction context?

Entering or leaving an SP should not start or end a transaction.

* optional: SPs can return multisets (ala SQL Server).

I think that's important.

** question: how would multisets be handled on the client end?

In previous discussions there seemed to be a feeling that unless we
were going to go to a new major version of the protocol, the return
from an SP would be an array of result sets. We would probably want
to reserve the first one for OUT parameters (and if we decide to
support it, the return value). Tools like psql would need to
display each in its turn, similar to what we do for some backslash
commands.

-Kevin

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

Josh Berkus <josh@agliodbs.com> wrote:

** question: if an SP is called by another SP, what is its
transaction context?

Entering or leaving an SP should not start or end a transaction.

That all sounds mighty hand-wavy and at serious risk of tripping over
implementation details. Some things to think about:

1. Are you expecting the procedure definition to be fetched from a
system catalog? You're going to need to be inside a transaction
to do that.

2. Are you expecting the procedure to take any input parameters?
You're going to need to be inside a transaction to evaluate the
inputs, unless perhaps you restrict the feature to an extremely
lobotomized subset of possible arguments (no user-defined types,
no expressions, just for starters).

3. What sort of primitive operations do you expect the SP to be
able to execute "outside a transaction"? The plpgsql model where
all the primitive operations are really SQL ain't gonna work.

I think that we could finesse #1 and #2, along these lines:
The CALL command is ordinary SQL but not allowed inside a transaction
block, much like some existing commands like VACUUM. So we start a
transaction to parse and execute it. The CALL looks up the procedure
definition and evaluates any input arguments. It then copies this info to
some outside-the-transaction memory context, terminates its transaction,
and calls the procedure. On return it starts a new transaction, in
which it can call the output functions that are going to have to be
executed in order to pass anything back to the client. (This implies
that OUT argument values are collected up during SP execution and not
actually passed back to the client till later. People who were hoping
to stream vast amounts of data to the client will not be happy. But
I see no way around that unless you want to try to execute output
functions outside a transaction, which strikes me as a quagmire.)

I'm less sure what to do about #3. The most attractive approach would
probably be to make people use a non-SQL script interpreter --- perl,
python, or whatever floats your boat --- which would likely mean that
we have not just one SP implementation language but N of them. But
we've solved that problem before.

Calling another SP ... particularly one with a different implementation
language ... could be a bit tricky too. The above proposal assumes that
SPs are always entered outside a transaction, but do we want to make
that same restriction for the call-another-SP case? And if not, how's
it going to work? Again, you'll have to be inside a transaction at
least long enough to get the SP's definition out of the catalogs.

regards, tom lane

On Thu, Apr 21, 2011 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

3. What sort of primitive operations do you expect the SP to be
able to execute "outside a transaction"?  The plpgsql model where
all the primitive operations are really SQL ain't gonna work.
I'm less sure what to do about #3.  The most attractive approach would
probably be to make people use a non-SQL script interpreter --- perl,
python, or whatever floats your boat --- which would likely mean that
we have not just one SP implementation language but N of them.  But
we've solved that problem before.

Does this mean you do or don't expect plpgsql to be able to run as
procedure? Should SPI based routines generally be able to run as a
procedure (I hope so)? If so, what API enhancements would be needed?
(I was thinking, SPI_is_proc, or something like that). I'd like to
see plpgsql work as much as possible as it does now, except obviously
you can't have exception handlers.

What about cancelling? Cancel the current running query, or the whole
procedure (I'm assuming the latter? How would that work?

Calling another SP ... particularly one with a different implementation
language ... could be a bit tricky too.  The above proposal assumes that
SPs are always entered outside a transaction, but do we want to make
that same restriction for the call-another-SP case?  And if not, how's
it going to work?  Again, you'll have to be inside a transaction at
least long enough to get the SP's definition out of the catalogs.

This restriction (no transaction only CALL) is ok I think. You can
always code up a function otherwise.

merlin

2011/4/21 Tom Lane <tgl@sss.pgh.pa.us>:

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

Josh Berkus <josh@agliodbs.com> wrote:

** question: if an SP is called by another SP, what is its
transaction context?

Entering or leaving an SP should not start or end a transaction.

That all sounds mighty hand-wavy and at serious risk of tripping over
implementation details.  Some things to think about:

It doesn't mean so SQL are inside SP non transactional. Stored
Procedure is just client module moved on server. You can call SQL
statements from psql without outer implicit or explicit transaction
too.

It mean - a CALL statement should not start a outer transaction when
it isn't requested, but all inner SQL statements runs in own
transactions.

The questions about mutable or immutable parameters are important -
but it doesn't mean so SP without outer transactions are impossible.

Regards

Pavel

On Thu, Apr 21, 2011 at 2:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

Josh Berkus <josh@agliodbs.com> wrote:

** question: if an SP is called by another SP, what is its
transaction context?

Entering or leaving an SP should not start or end a transaction.

That all sounds mighty hand-wavy and at serious risk of tripping over
implementation details.  Some things to think about:

1. Are you expecting the procedure definition to be fetched from a
system catalog?  You're going to need to be inside a transaction
to do that.

2. Are you expecting the procedure to take any input parameters?
You're going to need to be inside a transaction to evaluate the
inputs, unless perhaps you restrict the feature to an extremely
lobotomized subset of possible arguments (no user-defined types,
no expressions, just for starters).

3. What sort of primitive operations do you expect the SP to be
able to execute "outside a transaction"?  The plpgsql model where
all the primitive operations are really SQL ain't gonna work.

I think we could handle a lot of these details cleanly if we had
autonomous transactions as a system primitive. When you enter a
stored procedure at the outermost level, you begin a transaction,
which will remain open until the outermost stored procedure exits.
Any transactions that the stored procedure begins, commits, or rolls
back are in fact autonomous subtransactions under the hood. Possibly
conditions like IF (1/0) THEN ... END IF that throw run time errors
get evaluated in the outer transaction context, so any errors stops
execution at that point - and we also avoid beginning and ending a
gabazillion transactions.

Possibly I am still waving my hands.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Apr 21, 2011 at 2:37 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, Apr 21, 2011 at 2:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

Josh Berkus <josh@agliodbs.com> wrote:

** question: if an SP is called by another SP, what is its
transaction context?

Entering or leaving an SP should not start or end a transaction.

That all sounds mighty hand-wavy and at serious risk of tripping over
implementation details.  Some things to think about:

1. Are you expecting the procedure definition to be fetched from a
system catalog?  You're going to need to be inside a transaction
to do that.

2. Are you expecting the procedure to take any input parameters?
You're going to need to be inside a transaction to evaluate the
inputs, unless perhaps you restrict the feature to an extremely
lobotomized subset of possible arguments (no user-defined types,
no expressions, just for starters).

3. What sort of primitive operations do you expect the SP to be
able to execute "outside a transaction"?  The plpgsql model where
all the primitive operations are really SQL ain't gonna work.

I think we could handle a lot of these details cleanly if we had
autonomous transactions as a system primitive.  When you enter a
stored procedure at the outermost level, you begin a transaction,
which will remain open until the outermost stored procedure exits.

If you do it that (base it on AT) way, then you can't:
1) call any utility command (vacuum, etc)
2) run for an arbitrary amount of time
3) discard any locks (except advisory)
4) deal with serialization isolation/mvcc snapshot issues that plague functions.

Points 2 & (especially) 4 for me are painful.

#4 explained:
If you are trying to tuck all the gory mvcc details into server side
functions, there is no real effective way to prevent serialization
errors because the snapshot is already made when you enter the
function. Even if you LOCK something on function line#1, it's already
too late. No transaction procedures don't have this problem and allow
encapsulating all that nastiness in the server.

merlin

On Thu, Apr 21, 2011 at 3:51 PM, Merlin Moncure <mmoncure@gmail.com> wrote:

On Thu, Apr 21, 2011 at 2:37 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, Apr 21, 2011 at 2:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

Josh Berkus <josh@agliodbs.com> wrote:

** question: if an SP is called by another SP, what is its
transaction context?

Entering or leaving an SP should not start or end a transaction.

That all sounds mighty hand-wavy and at serious risk of tripping over
implementation details.  Some things to think about:

1. Are you expecting the procedure definition to be fetched from a
system catalog?  You're going to need to be inside a transaction
to do that.

2. Are you expecting the procedure to take any input parameters?
You're going to need to be inside a transaction to evaluate the
inputs, unless perhaps you restrict the feature to an extremely
lobotomized subset of possible arguments (no user-defined types,
no expressions, just for starters).

3. What sort of primitive operations do you expect the SP to be
able to execute "outside a transaction"?  The plpgsql model where
all the primitive operations are really SQL ain't gonna work.

I think we could handle a lot of these details cleanly if we had
autonomous transactions as a system primitive.  When you enter a
stored procedure at the outermost level, you begin a transaction,
which will remain open until the outermost stored procedure exits.

If you do it that (base it on AT) way, then you can't:
1) call any utility command (vacuum, etc)
2) run for an arbitrary amount of time
3) discard any locks (except advisory)
4) deal with serialization isolation/mvcc snapshot issues that plague functions.

Points 2 & (especially) 4 for me are painful.

#4 explained:
If you are trying to tuck all the gory mvcc details into server side
functions, there is no real effective way to prevent serialization
errors because the snapshot is already made when you enter the
function.  Even if you LOCK something on function line#1, it's already
too late.  No transaction procedures don't have this problem and allow
encapsulating all that nastiness in the server.

Yes, those sound like a potent set of restrictions that "gut" what the
facility ought to be able to be useful for.

If what you want is something that runs inside a pre-existing
transaction, that rules out doing VACUUM or, really, *anything* that
generates transactions, without jumping through hoops to try to change
their behaviour.

My preference would be to expect that stored procedures are sure to
generate at least one transaction, and potentially as many more as
they choose to generate.

One of the most recent things I implemented was a process that does
bulk updates to customer balances. We don't want the balance tuples
locked, so the process needs to COMMIT after each update.

At present, that means I'm doing a round trip from client to server each time.

If I had these "autonomous transaction procedures," I could perhaps do
the whole thing in a stored procedure, which would:
a) Pull the list of transactions it's supposed to process;
b) Loop on them:
- BEGIN; Do the processing for a transaction, COMMIT.

That's not terribly different from a vacuum utility that:
a) Pulls a list of tables it's supposed to vacuum;
b) Loop on them:
VACUUM the table

Autovac ought to make that sort of thing limitedly useful; you'd
usually rather just use autovac.

Mind you, we might discover that implementing autovac mostly in the
stored procedure language is easier and better than having it mostly
in C. And this might further make it easy to add "hooks" to allow
site-specific logic to affect autovacuum policy.

(Note that Slony-I version 1.0, 1.1, and possibly 1.2 had the 'cleanup
thread' which notably vacuums tables mostly written in C. 2.0 shifted
the bulk of the logic into pl/pgsql, which made it much simpler to
read and verify, and made some of the components usable by
administrators.)

I'd expect SP to NOT be nestable, or at least, not in a sense that
allows rolling back activity of a "child" that thought it COMMITed
work.

It seems to me that we've already got perfectly good stored functions
that are strictly inside an existing transactional context - if you
want logic that's doing that, then use a SF, that's already perfectly
good for that, and you should use that. If you want a stored
procedure that runs its own transaction(s), do so; don't expect every
kind of transactional logic out of SPs.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

Peter Eisentraut wrote:

So the topic of "real" "stored procedures" came up again. Meaning a
function-like object that executes outside of a regular transaction,
with the ability to start and stop SQL transactions itself.

I would like to collect some specs on this feature. So does anyone have
links to documentation of existing implementations, or their own spec
writeup? A lot of people appear to have a very clear idea of this
concept in their own head, so let's start collecting those.

I've thought a lot about this too.

The general case of a stored procedure should be all powerful, and be able to
directly invoke any code written in SQL or other languages that a DBMS client
can directly invoke on the DBMS, as if it were a client, but that the procedure
is stored and executed entirely in the DBMS. But the stored procedure also has
its own lexical variables and supports conditionals and iteration and recursion.

A stored procedure is invoked as a statement and doesn't have a "return" value;
in contrast, a function has a return value and is invoked within a value
expression of a statement. A stored procedure can see and update the database,
and can have IN/INOUT/OUT parameters. A stored procedure can have side-effects
out of band, such as user I/O, if Pg supports that.

The general stored procedure should be orthogonal to other concerns, in
particular to transactions and savepoints; executing one should not should not
implicitly start or commit or rollback a transaction or savepoint. However, it
should be possible to explicitly declare that procedure is a transaction, so
that starts and ends are neatly paired regardless of how the procedure exits,
that is a transaction lifetime is attached to its lexical scope, but this would
be optional.

A stored procedure should be able to do data manipulation, data definition,
explicit transaction control (except perhaps when defined to be a transaction),
privilege control, message passing, and so on.

As for semantics, lets say that when a stored procedure is invoked, its
definition will be pulled from the system catalog in a snapshot and be compiled,
then run normally no matter what it does, even if the definition of the
procedure itself is changed during its execution; in the latter case, it just
means that once the execution finishes, subsequent calls to it would then call
the updated version or fail. So just compiling the procedure may need a catalog
lock or whatever, but when it starts executing a transaction isn't required.

Any stored procedure in general should be able to invoke stored procedures, to
any level of nesting, just like in any normal programming language. There might
be restrictions on what individual procedures can do depending on how they're
declared; for example, if one is declared to have a scope-bound transaction,
then it or ones it invokes can't have explicit transaction control statements.
But such restrictions are an orthogonal or case-dependent matter.

(When we have a distinct stored procedure, I also believe that a stored function
should be more restricted, such as only having IN parameters and not being able
to see the database but by way of parameters, and that it should be
deterministic. But that ship has sailed and I'm not going to argue for any
changes to functions.)

-- Darren Duncan

Merlin Moncure <mmoncure@gmail.com> writes:

On Thu, Apr 21, 2011 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

3. What sort of primitive operations do you expect the SP to be
able to execute "outside a transaction"? �The plpgsql model where
all the primitive operations are really SQL ain't gonna work.

Does this mean you do or don't expect plpgsql to be able to run as
procedure? Should SPI based routines generally be able to run as a
procedure (I hope so)? If so, what API enhancements would be needed?
(I was thinking, SPI_is_proc, or something like that). I'd like to
see plpgsql work as much as possible as it does now, except obviously
you can't have exception handlers.

You can't have arithmetic, comparisons, or much of anything outside a
transaction with plpgsql. That model just plain doesn't work for this
purpose, I think. You really want a control language that's independent
of the SQL engine, and for better or worse plpgsql is built inside that
engine.

What about cancelling? Cancel the current running query, or the whole
procedure (I'm assuming the latter? How would that work?

Good question. If you're imagining that the SP could decide to cancel a
database request partway through, it seems even further afield from what
could reasonably be done in a single-threaded backend.

Maybe we should think about the SP controlling a second backend (or even
multiple backends?) that's executing the "transactional" operations.
dblink on steroids, as it were.

regards, tom lane

Robert Haas <robertmhaas@gmail.com> writes:

EDB has an implementation of this in Advanced Server. A stored
procedure can issue a COMMIT, which commits the current transaction
and begins a new one. This might or might not be what people are
imagining for this feature. If we end up doing something else, one
thing to consider is the impact on third-party tools like PGPOOL,
which currently keep track of whether or not a transaction is in
progress by snooping on the stream of SQL commands. If a procedure
can be started with no transaction in progress and return with one
open, or the other way around, that method will break horribly.
That's not necessarily a reason not to do it, but I suspect we would
want to add some kind of protocol-level information about the
transaction state instead so that such tools could continue to work.

Huh? There's been a transaction state indicator in the protocol since
7.4 (see ReadyForQuery). It's not our problem if PGPOOL is still using
methods that were appropriate ten years ago.

Pgpool has been using the info since 2004 (7.4 was born in 2003).
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

On 4/21/11 3:07 PM, Tom Lane wrote:

Maybe we should think about the SP controlling a second backend (or even
multiple backends?) that's executing the "transactional" operations.
dblink on steroids, as it were.

This is how people are doing this now (using dblink I mean).

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

Josh Berkus <josh@agliodbs.com> writes:

On 4/21/11 3:07 PM, Tom Lane wrote:

Maybe we should think about the SP controlling a second backend (or even
multiple backends?) that's executing the "transactional" operations.
dblink on steroids, as it were.

This is how people are doing this now (using dblink I mean).

Right, and it works. But it's notationally painful, management of the
connection information poses security issues, etc etc. Perhaps those
sorts of things could be addressed, though.

regards, tom lane

On Apr 21, 2011, at 3:51 PM, Merlin Moncure <mmoncure@gmail.com> wrote:

If you do it that (base it on AT) way, then you can't:
1) call any utility command (vacuum, etc)
2) run for an arbitrary amount of time
3) discard any locks (except advisory)
4) deal with serialization isolation/mvcc snapshot issues that plague functions.

It is not obvious to me that you cannot do these things.

...Robert