Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> Adam Sjøgren wrote:
>>
>>> Enclosed is a tiny patch for plperl that puts the schema-name of the
>>> current table in $_TD, so triggers can access tables using
>>> schemaname.tablename, for instance like so:
>>>
>
>
>> This seems like a good idea, but we should probably make analogous
>> changes for plpgsql, pltcl and plpython. Having different trigger data
>> available in some of these doesn't seem like a good idea.
>>
>
> Yeah. I'm also a little disturbed by using "nspname" which is an
> entirely internal name; plus it's a bit unclear *which* schema it's
> supposed to be. (One might think it's the schema the trigger function
> is in, for instance.) Somebody established a bad precedent by using
> "relname" for the table name.
>
> Maybe we should use field names like "table_name" and "table_schema".
> "relname" could be kept around for awhile but deprecated as a duplicate
> of "table_name".
>
> Or if that seems too messy, keep "relname" but use "relschema" as the
> new field.
>
> regards, tom lane
>
>
Here are the various bits of trigger data our languages get:
plpgsql (function variables) : NEW OLD TG_NAME TG_WHEN TG_LEVEL TG_OP
TG_RELID TG_RELNAME TH_NARGS TG_ARGV[]
plperl (keys in %$_TD): new old name event when level relid relname
argc args
plpython (keys of TD): new old name event when level relid args
pltcl: (function variables) $TG_name $TG_relid $TG_relatts $TG_when
$TG_level $TG_op $NEW $OLD $args
plpython and pltcl don't have relname, while only pltcl has relatts. Is
relatts useful? should we provide it everywhere?
I propose to add relname to plpython and pltcl, and relschema to all
(mutatis mutandis w.r.t. names).
cheers
andrew