Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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




---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to