From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alex Pilosov <alex(at)pilosoft(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUG] views and functions on relations |
Date: | 2001-04-19 01:44:08 |
Message-ID: | 17255.987644648@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> Something (when the query is evaluated, before cust_name function is
> called) sets the tupdesc->natts=0,
Ugh. You verified the natts is wrong in the tupdesc?
> 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?
The tupdesc natts *must* match the actual tuple, else all sorts of
things will go wrong. I don't think SPI_gettypeid is broken.
> 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).
That seems moderately unlikely, since \d doesn't depend on SPI...
> You may have more luck tracing the
> code which improperly sets nattrs than me...
Hard to do without a working (failing ;-)) example to look at.
Have you had any luck reducing your example? Alternatively,
would you be willing to give me telnet or ssh access to your
machine, and I'll look at the problem in situ?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Myers | 2001-04-19 02:01:01 | Re: timeout on lock feature |
Previous Message | Bruce Momjian | 2001-04-19 01:42:35 | Re: Re: No printable 7.1 docs?y |