From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Marko Tiikkaja <marko(at)joh(dot)to>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [HACKERS] plpgsql - additional extra checks |
Date: | 2018-03-02 21:30:43 |
Message-ID: | CAFj8pRC_bP-q6iemFSo8O4orKQndm05iC7FD44sLwfQCuLwnuA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
2018-03-01 21:14 GMT+01:00 David Steele <david(at)pgmasters(dot)net>:
> Hi Pavel,
>
> On 1/7/18 3:31 AM, Pavel Stehule wrote:
> >
> > There, now it's in the correct Waiting for Author state. :)
> >
> > thank you for comments. All should be fixed in attached patch
>
> This patch no longer applies (and the conflicts do not look trivial).
> Can you provide a rebased patch?
>
> $ git apply -3 ../other/plpgsql-extra-check-180107.patch
> error: patch failed: src/pl/plpgsql/src/pl_exec.c:5944
> Falling back to three-way merge...
> Applied patch to 'src/pl/plpgsql/src/pl_exec.c' with conflicts.
> U src/pl/plpgsql/src/pl_exec.c
>
> Marked as Waiting on Author.
>
I am sending updated code. It reflects Tom's changes - now, the rec is used
as row type too, so the checks must be on two places. With this update is
related one change. When result is empty, then the extra checks doesn't
work - PLpgSQL runtime doesn't pass necessary tupledesc. But usually, when
result is empty, then there are not problems with missing values, because
every value is NULL.
Regards
Pavel
>
> Thanks,
> --
> -David
> david(at)pgmasters(dot)net
>
Attachment | Content-Type | Size |
---|---|---|
plpgsql-extra-check-180302.patch | text/x-patch | 17.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-03-02 21:34:42 | Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan |
Previous Message | Pavel Stehule | 2018-03-02 21:11:44 | Re: Cached/global query plans, autopreparation |