Re: [BUG] views and functions on relations - Mailing list pgsql-hackers

Here's more info on the bug:

background: function cust_name(customers) returns varchar;
Query in question:

SELECT
cust_name(a)
FROM customers AS a, addresses AS b
WHERE
b.cust_id=a.cust_id
and b.oid=get_billing_record(a.cust_id)
and cust_balance(a.cust_id)>0

First, my idea of what's happening:

Tuple in question contains the row from 'customers' table.

Something (when the query is evaluated, before cust_name function is
called) sets the tupdesc->natts=0, however, everything else in that
tupdesc is right (all the attrs are present and have correct values and
atttypes), and tuple->t_data->t_natts is correct (12).

When SPI_getbinval is called, it checks tuple->t_data->t_natts, and works
OK, but, however, when SPI_gettypeid is called, it checks
tupledesc->nattrs, and returns 0. 

Question: Should SPI_gettypeid look at tuple->t_data->t_natts (to do that,
it needs to be passed tuple along with tupdesc)? 
Or some other code should be fixed to properly set tupledesc->nattrs?

NOTE: when I removed the check in SPI_gettypeid, it _also_ fixed the '\d
viewname' bug, so these two bugs are related (i.e. you cannot see \d
because nattrs is set incorrectly). You may have more luck tracing the
code which improperly sets nattrs than me...

Hoping for proper fix, 


-alex

traceback:
#0  elog (lev=-1, fmt=0x45d4b340 "cache lookup for type %u failed")   at elog.c:119
#1  0x45d4693e in exec_cast_value (value=1791, valtype=0, reqtype=23,   reqinput=0x82bfdb0, reqtypelem=0, reqtypmod=-1,
isnull=0xbfffeb6f"")   at pl_exec.c:2682
 
#2  0x45d45f19 in exec_assign_value (estate=0xbfffec40, target=0x82cdd88,   value=1791, valtype=0, isNull=0xbfffeb6f
"")at pl_exec.c:2173
 
#3  0x45d4687a in exec_move_row (estate=0xbfffec40, rec=0x0,
row=0x82bfcc8,   tup=0x827a170, tupdesc=0x827a130) at pl_exec.c:2629
#4  0x45d43e64 in plpgsql_exec_function (func=0x82b3188, fcinfo=0x828e364)   at pl_exec.c:331
#5  0x45d41f57 in plpgsql_call_handler (fcinfo=0x828e364) at
pl_handler.c:128
#6  0x80b78ad in ExecMakeFunctionResult (fcache=0x828e350,   arguments=0x826eb28, econtext=0x826fc98, isNull=0xbfffed37
"",  isDone=0xbfffed68) at execQual.c:796
 
#7  0x80b794e in ExecEvalFunc (funcClause=0x826ead8, econtext=0x826fc98,   isNull=0xbfffed37 "", isDone=0xbfffed68) at
execQual.c:890
#8  0x80b7d1c in ExecEvalExpr (expression=0x826ead8, econtext=0x826fc98,   isNull=0xbfffed37 "", isDone=0xbfffed68) at
execQual.c:1215
#9  0x80b7fbb in ExecTargetList (targetlist=0x826e6a0, nodomains=19,   targettype=0x8284620, values=0x8285100,
econtext=0x826fc98,  isDone=0xbfffef08) at execQual.c:1536
 
#10 0x80b8215 in ExecProject (projInfo=0x82850d8, isDone=0xbfffef08)   at execQual.c:1764
#11 0x80bcd9a in ExecNestLoop (node=0x826e5c0) at nodeNestloop.c:245
#12 0x80b6b76 in ExecProcNode (node=0x826e5c0, parent=0x826e5c0)   at execProcnode.c:297
#13 0x80b5eee in ExecutePlan (estate=0x826f770, plan=0x826e5c0,   operation=CMD_SELECT, numberTuples=0,
direction=ForwardScanDirection,  destfunc=0x8285de0) at execMain.c:973
 
#14 0x80b5463 in ExecutorRun (queryDesc=0x826f758, estate=0x826f770,   feature=3, count=0) at execMain.c:233
#15 0x80f76b3 in ProcessQuery (parsetree=0x82433e8, plan=0x826e5c0,   dest=Remote) at pquery.c:295
#16 0x80f62bb in pg_exec_query_string (   query_string=0x8243090 "select * from outstanding_balances;",
dest=Remote,   parse_context=0x8218730) at postgres.c:810
#17 0x80f71e6 in PostgresMain (argc=4, argv=0xbffff1e0, real_argc=8,   real_argv=0xbffffaf4, username=0x81cbf69 "sw")
atpostgres.c:1908
 
#18 0x80e14c3 in DoBackend (port=0x81cbd00) at postmaster.c:2111
#19 0x80e10ac in BackendStartup (port=0x81cbd00) at postmaster.c:1894
#20 0x80e0436 in ServerLoop () at postmaster.c:992
#21 0x80dfe63 in PostmasterMain (argc=8, argv=0xbffffaf4) at
postmaster.c:682
#22 0x80c4055 in main (argc=8, argv=0xbffffaf4) at main.c:151