Tom Lane <[email protected]> wrote:
> I think what you want to do instead is use PG_TRY blocks to ensure that
> transient results are cleaned up.
I think PG_TRY blocks are not enough, too. PG_TRY requires a statement
block, but we need to return from dblink functions per tuple.
Error and interruption can occur at the caller:
ExecMakeTableFunctionResult()
{
for (;;)
{
*here* CHECK_FOR_INTERRUPTS();
result = FunctionCallInvoke(&fcinfo); => { PG_TRY ... END }
if (rsinfo.isDone == ExprEndResult)
break;
tuplestore_puttuple(tupstore, &tmptup);
}
}
Also, we should think SRF-functions might not be called repeatedly
until max_calls whether the transaction is committed or rollbacked
because we might have some optimization in FunctionScan in the future.
For example:
SELECT * FROM dblink() LIMIT 3
might call dblink() only 3 times if we optimize executor logic
(it should not occur for now, though).
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
