Hi Tom,
> > Does that make any sense? Is it worth the work? Or should we just tell
> > anyone who actually needs it (I don't, at present) 'use another PL'?
>
> I don't really see this going anywhere --- it's contorting the semantics
> of plpgsql too much for too little gain.
Yup, the last bit was definitely contortionist! Prob should have split
it into two separate posts.
What I'm most looking for comments on what's actually in the patch: with
it I can use NEW.($1). _That_ is a big gain.
On the rest...
> Your proposal doesn't address the
> issue of how the function would find out the column names in order to
> make use of the proposed notation;
It doesn't need them. The posted patch already allows:
for i in 1..3 loop myvar := rec.(i);
end loop;
...so long as all cols have the same datatype (note that col numbers are
1-based, like in the spi funcs).
> and as you noted there's still a
> serious problem with varying datatypes.
My contortions were an attempt to think my way around the varying
datatypes problem. Obviously my thinking got tied in knots ;) I agree,
that part is too much work for too little gain.
> Either plperl or pltcl (probably also plpython but I'm not familiar
> with that language) is a better choice for writing such triggers,
> because those languages already have answers for all these issues.
I didn't think plperl could be used to write triggers. Is this new in 8?
As an application developer, though, it'd be nice to keep everything in
one pl language, and ideally one guaranteed available (or easily
installable without other dependencies) on every postgres db out there.
That's pretty much why I wrote the patch: to add the one missing feature
I need to write my generic triggers in plpgsql.
Regards,
Matt
