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
