Re: [HACKERS] plpgsql - additional extra checks

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] plpgsql - additional extra checks
Дата
Msg-id CAFj8pRB5XyrhNGEKNgEfRY7zT7Uz3sbj=zLqcOo_r7NbQL6Fyw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] plpgsql - additional extra checks  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] plpgsql - additional extra checks  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Hi

2017-11-30 3:44 GMT+01:00 Michael Paquier <michael.paquier@gmail.com>:
On Wed, Sep 13, 2017 at 12:51 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
>
> 2017-09-13 1:42 GMT+02:00 Daniel Gustafsson <daniel@yesql.se>:
>>
>> > On 08 Apr 2017, at 15:46, David Steele <david@pgmasters.net> wrote:
>> >
>> >> On 1/13/17 6:55 AM, Marko Tiikkaja wrote:
>> >>> On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby <Jim.Nasby@bluetreble.com
>> >>> <mailto:Jim.Nasby@bluetreble.com>> wrote:
>> >>>
>> >>>    On 1/11/17 5:54 AM, Pavel Stehule wrote:
>> >>>
>> >>>        +    <term><varname>too_many_rows</varname></term>
>> >>>        +    <listitem>
>> >>>        +     <para>
>> >>>        +      When result is assigned to a variable by
>> >>>        <literal>INTO</literal> clause,
>> >>>        +      checks if query returns more than one row. In this case
>> >>>        the assignment
>> >>>        +      is not deterministic usually - and it can be signal some
>> >>>        issues in design.
>> >>>
>> >>>
>> >>>    Shouldn't this also apply to
>> >>>
>> >>>    var := blah FROM some_table WHERE ...;
>> >>>
>> >>>    ?
>> >>>
>> >>>    AIUI that's one of the beefs the plpgsql2 project has.
>> >>>
>> >>>
>> >>> No, not at all.  That syntax is undocumented and only works because
>> >>> PL/PgSQL is a hack internally.  We don't use it, and frankly I don't
>> >>> think anyone should.
>> >
>> > This submission has been moved to CF 2017-07.
>>
>> This patch was automatically marked as “Waiting for author” since it needs
>> to
>> be updated with the macro changes in
>> 2cd70845240087da205695baedab6412342d1dbe
>> to compile.  Changing to using TupleDescAttr(); makes it compile again.
>> Can
>> you submit an updated version with that fix Pavel?
>
>
> I am sending fixed patch

+   <para>
+    The setting <varname>plpgsql.extra_warnings</> to <literal>all</> is a
+    good idea in developer or test environments.
+   </para>
At least documentation needs patching, or this is going to generate
warnings on HEAD at compilation. I am moving this to next CF for lack
of reviews, and the status is waiting on author as this needs at least
a couple of doc fixes.

fixed doc attached

Regards

Pavel
 
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] SQL procedures
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Refactoring identifier checks to consistently use strcmp