So, why shouldn't SET CONSTRAINTS set a transaction snapshot?

In connection with fixing
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00620.php
I decided to insert "Assert(ActiveSnapshotSet())" into pg_plan_query,
since any path reaching that function should already have provided
a snapshot.  I was bemused to find that this resulted in an assert
failure in the regression tests, with backtrace

#4  0x480b74 in ExceptionalCondition (   conditionName=0x169630 "!(ActiveSnapshotSet())",    errorType=0x169648
"FailedAssertion",fileName=0x169564 "postgres.c",    lineNumber=689) at assert.c:57
 
#5  0x3a5a4c in pg_plan_query (querytree=0x4017d288, cursorOptions=1565885,    boundParams=0x7b033ec8) at
postgres.c:689
#6  0x3a5b98 in pg_plan_queries (querytrees=0x7b011c28, cursorOptions=32,    boundParams=0x7f, needSnapshot=-24 '�') at
postgres.c:772
#7  0x2eac74 in _SPI_prepare_plan (src=0x1 <Address 0x1 out of bounds>,    plan=0x17e4bd, boundParams=0x7b03cf5a) at
spi.c:1609
#8  0x2e8654 in SPI_prepare_cursor (   src=0x40172468 "SELECT 1 FROM ONLY \"public\".\"pktable\" x WHERE \"id\"
OPERATOR(pg_catalog.=)$1 FOR SHARE OF x", nargs=1, argtypes=0x7b03c300,    cursorOptions=0) at spi.c:499
 
#9  0x2e8590 in SPI_prepare (src=0x7b011c28 "", nargs=2063845116,    argtypes=0x7b011cf0) at spi.c:473
#10 0x44a024 in ri_PlanCheck (   querystr=0x40172468 "SELECT 1 FROM ONLY \"public\".\"pktable\" x WHERE \"id\"
OPERATOR(pg_catalog.=)$1 FOR SHARE OF x", nargs=1, argtypes=0x7b03c300,    qkey=0x7b03be40, fk_rel=0x4014ba78,
pk_rel=0x40142b38,cache_plan=1)   at ri_triggers.c:3225
 
#11 0x4456fc in RI_FKey_check (fcinfo=0x7b011c28) at ri_triggers.c:486
#12 0x4457e4 in RI_FKey_check_ins (fcinfo=0x7b011c28) at ri_triggers.c:518
#13 0x2a3f70 in ExecCallTriggerFunc (trigdata=0x7b03b868, tgindx=0,    finfo=0x7b03bb30, instr=0x0,
per_tuple_context=0x401eaf20)  at trigger.c:1591
 
#14 0x2a5a74 in AfterTriggerExecute (event=0x40174890, rel=0x4014ba78,    trigdesc=0x7b011cf0, finfo=0x40127948,
instr=0x0,   per_tuple_context=0x401eaf20) at trigger.c:2777
 
#15 0x2a5de0 in afterTriggerInvokeEvents (events=0x40174c70, firing_id=1,    estate=0x401276b8, delete_ok=1 '\001') at
trigger.c:2956
#16 0x2a6f4c in AfterTriggerSetState (stmt=0x400cd9f8) at trigger.c:3729
#17 0x3aef54 in ProcessUtility (parsetree=0x400cd9f8,    queryString=0x400cd1a8 "SET CONSTRAINTS ALL IMMEDIATE;",
params=0x0,   isTopLevel=1 '\001', dest=0x400cdbe0, completionTag=0x7b03b348 "")   at utility.c:1036
 
#18 0x3ac9f8 in PortalRunUtility (portal=0x4011c438, utilityStmt=0x400cd9f8,    isTopLevel=1 '\001', dest=0x400cdbe0,
completionTag=0x7b03b348"")   at pquery.c:1183
 
#19 0x3acba8 in PortalRunMulti (portal=0x4011c438, isTopLevel=1 '\001',    dest=0x400cdbe0, altdest=0x400cdbe0,
completionTag=0x7b03b348"")   at pquery.c:1288
 
#20 0x3ac224 in PortalRun (portal=0x4011c438, count=2147483647,    isTopLevel=1 '\001', dest=0x400cdbe0,
altdest=0x400cdbe0,   completionTag=0x7b03b348 "") at pquery.c:815
 
#21 0x3a5fe4 in exec_simple_query (   query_string=0x400cd1a8 "SET CONSTRAINTS ALL IMMEDIATE;")   at postgres.c:1011

The problem here is that PortalRunUtility() intentionally does not set
a snapshot for ConstraintsSetStmt; so if SET CONSTRAINTS IMMEDIATE
results in any triggers getting fired, those triggers are run with
no snapshot available.  Boo hiss.

The comment in PortalRunUtility asserts loudly that ConstraintsSetStmt
MUST NOT have a transaction snapshot set before it is executed, but
I confess that I don't see why not at the moment.  We certainly can't
have it not set a snap if it has any triggers to fire.  Comments?
        regards, tom lane