Re: [HACKERS] plpgsql - additional extra checks
От | Pavel Stehule |
---|---|
Тема | Re: [HACKERS] plpgsql - additional extra checks |
Дата | |
Msg-id | CAFj8pRA7p_+ChN0Usw6Bm0+VBPo-zCY_ghtERcUtV+e_sZi+2A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] plpgsql - additional extra checks (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: [HACKERS] plpgsql - additional extra checks
|
Список | pgsql-hackers |
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
Regards
Pavel
Stephen, you signed up to review this patch in the previous Commitfest, do you
still intend to work on this?
cheers ./daniel
Вложения
В списке pgsql-hackers по дате отправления: