2014-07-29 9:41 GMT+02:00 Marti Raudsepp <ma...@juffo.org>: > On Tue, Jul 29, 2014 at 9:49 AM, Pavel Stehule <pavel.steh...@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). Regards Pavel > > Regards, > Marti >
