| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: row literal problem |
| Date: | 2012-07-20 17:13:21 |
| Message-ID: | 26635.1342804401@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Fri, Jul 20, 2012 at 1:31 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Here's a draft patch for that. It wasn't quite as ugly as I feared.
>> A lot of the apparent bulk of the patch is because I chose to split
>> ExecEvalVar into separate functions for the scalar and whole-row
>> cases, which seemed appropriate because they now get different
>> ExprState node types.
> Thanks for that! Applying the patch and confirming the fix turned up
> no issues. I did a perfunctory review and it all looks pretty good:
> maybe ExecInitExpr could use a comment describing the
> InvalidAttrNumber check though...it's somewhat common knowledge that
> InvalidAttrNumber means row variables but it's also used to initialize
> variables before loops scans and things like that.
Thanks for testing. I added the suggested comment and made some other
cosmetic improvements, and have committed this.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2012-07-20 17:15:12 | Re: isolation check takes a long time |
| Previous Message | Robert Haas | 2012-07-20 17:12:32 | Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers) |