Re: PL/PgSQL: RAISE and the number of parameters

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.
>

In response to

Browse pgsql-hackers by date

  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