From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/PgSQL: RAISE and the number of parameters |
Date: | 2014-08-12 17:34:02 |
Message-ID: | CAFj8pRCX0TXt8Q7n1Q+cxtJ9WtjTEHFZ5pKOXT7O-SRDQCctdA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2014-08-12 19:14 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
> one note: this patch can enforce a compatibility issues - a partially
>> broken functions, where some badly written RAISE statements was executed
>> newer.
>>
>
> I am not against this patch, but it should be in extra check probably ??
>>
>
> I'm not sure about what you mean by "it should be in extra check".
>
> Or we have to documented it as potential compatibility issue.
>>
>
> Indeed, as a potential execution error is turned into a certain
> compilation error.
>
> If this compatibility point is a blocker, the compilation error can be
> turned into a warning, but I would prefer to keep it an error: I'm quite
> sure I fell into that pit at least once or twice.
>
I prefer error, although there is possibility to control a force of
exception - error or warning via extra plpgsql checks - this kind of error
is strange - and stored procedures usually can be fixed later because
plpgsql source is available.
There was a precedent with more precious query syntax check more times.
Just it should be well documented.
Regards
Pavel
>
> --
> Fabien.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-08-12 17:52:46 | Re: Supporting Windows SChannel as OpenSSL replacement |
Previous Message | Steve Crawford | 2014-08-12 17:26:24 | Re: Hokey wrong versions of libpq in apt.postgresql.org |