Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> Tom Lane wrote:
>>
>>> Perhaps it would help if we looked at some specific use-cases that
>>> people need, rather than debating abstractly. What do you need your
>>> generic trigger to *do*?
>>>
>
>
>> The two things I have wanted most badly in the past are
>>
>
>
>> a) to be able to address a field in NEW and OLD by a string name
>> (usually passed in via a trigger argument) and
>>
>
> But what are you then going to do with that field? Are you just
> assuming that it will be of a pre-agreed datatype? Or that you
> can perform some specific operation on it? What are you expecting
> will happen if it isn't or can't?
>
Yes, in many cases I'll assume it's a given datatype. A good example is
an auto-update-timestamp trigger where the name of the timestamp field
is passed in as a trigger argument.
>
>> b) to be able to discover the names if the fields in NEW and OLD
>>
>
> It doesn't seem hard or ugly to provide an API for that, but again
> I'm wondering what happens next.
>
One case I have is a custom audit package that ignores certain fields
when logging changes. So it would be nice to be able to iterate over the
field names and check if NEW.foo is distinct from OLD.foo, skipping the
field names we don't care about to decide if the change needs to be logged.
cheers
andrew