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>
> > I dislike this proposal - it is strongly inconsistent with current
> > 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
> 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
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
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).