From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Error check always bypassed in tablefunc.c |
Date: | 2015-01-30 01:40:17 |
Message-ID: | CAB7nPqTsNd_35Rwt7+v-FzYcWa_FM9OcK=7aWK-7OVa4_74GeQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 30, 2015 at 10:32 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> [blah]
> What I did about this was to leave the behavior alone in back branches,
> but insist on a type match in HEAD. I think we can reasonably tighten
> the type requirements in a new major release, but doing it in minor
> releases is probably a bad idea.
Hm. OK. I am fine with that for the back branches. Thanks for
tightening things on master as well.
> * I thought it was odd to throw an error for NULL input, especially
> an "infinite recursion" error. However, even with your patch the code
> would've dumped core on a null current_key value (since it would've
> passed a null start_with down to the next recursion level). What I
> changed it to was to omit the recursion test (and hence print the row)
> and then not recurse at a null. This seems consistent and reasonable.
This sounds reasonable to me as well.
> * I made a few other minor cleanups as well, in particular getting
> rid of some unnecessary pstrdup() steps.
Thanks!
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-01-30 01:42:23 | Re: Exposing the stats snapshot timestamp to SQL |
Previous Message | Tom Lane | 2015-01-30 01:32:20 | Re: Error check always bypassed in tablefunc.c |