On Tue, Jul 29, 2014 at 9:49 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > I dislike this proposal - it is strongly inconsistent with current trigger > design
The real point I was trying to convey (in my previous email) is that these declarations should be part of the trigger *function* not the function-to-table relationship. CREATE TRIGGER shouldn't be in the business of declaring new local variables for the trigger function. Whether we define new syntax for that or re-use the argument list is secondary.
But the inconsistency is deliberate, I find the current trigger API horrible. Magic variables... Text-only TG_ARGV for arguments... RETURNS trigger...
A notation RETURNS TRIGGER I don't like too much too - RETURNS void or RETURNS record are much more natural.
My dream is some like CREATE OR REPLACE TRIGGER FUNCTION trg() RETURNS RECORD
but it is only syntactic sugar - and I don't see any benefit why we should to implement it.
No way to invoke trigger functions directly for testing.
It is horrible idea. I can agree, it is a limit - but not too hard - there is simple possibility to take code from trigger to auxiliary function. But current design is simply and robust with few possible user errors.
By not imitating past mistakes, maybe we can eventually arrive at a language that makes sense.
Sorry I disagree. Can be subjective is this API is too or not too bad for redesign. More objective arguments - there are no performance issue, no security issue. I am thinking, so it has sense, so I don't see reason why to change it and why we should to have two API. Last argument, if we change something, then we should to use a ANSI SQL syntax everywhere it is possible (when we don't get any new special functionality).
