Re: pltcl - "Cache lookup for attribute" error - version 2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Patrick Samson <p_samson(at)yahoo(dot)com>
Cc: Jan Wieck <JanWieck(at)yahoo(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: pltcl - "Cache lookup for attribute" error - version 2
Date: 2004-01-23 15:52:51
Message-ID: 27154.1074873171@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Patrick Samson <p_samson(at)yahoo(dot)com> writes:
> Attribute names beginning with a dot are filtered
> just in one place, in pltcl_trigger_handler().
> (version 7.3.5)

I am not sure why that code is there. It is *not* there to prevent the
loop from touching dropped attributes, because the same code is in the
original 1.1 version of pltcl.c, long before we could drop attributes.
Jan, do you remember why you put this into pltcl_trigger_handler()?

/************************************************************
* Ignore pseudo elements with a dot name
************************************************************/
if (*(ret_values[i]) == '.') {
i += 2;
continue;
}

It's not documented behavior that I can see, and it doesn't seem to have
any use other than making pltcl triggers fail if a user chooses a field
name starting with a dot :-(

> Attached is a patch to :
> - Add a filter in two other places, in relation
> with the mentioned error message:
> pltcl_set_tuple_values()
> pltcl_build_tuple_argument()

This is already done in 7.4, although for some reason
pltcl_trigger_handler got overlooked - I will fix that.

> - Add the same filter in the build of TG_relatts.
> This will prevent a tcl script which loops on
> TG_relattrs to fail in trying to use a dropped
> column.

This is deliberately *not* done in 7.4, because it would break the
documented behavior of TG_relatts:

$TG_relatts

A Tcl list of the table column names, prefixed with an empty list
element. So looking up a column name in the list with
Tcl's lsearch command returns the element's number starting with 1
for the first column, the same way the
columns are customarily numbered in PostgreSQL.

I think we need to preserve the relationship to column numbers. People
who just want a list of the live columns can get it from the OLD or NEW
arrays.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Mark Cave-Ayland 2004-01-23 16:54:06 ANALYZE patch for review
Previous Message Tom Lane 2004-01-23 15:13:06 7.5 change documentation (was Re: cache control?)