Re: Boolean partitions syntax

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Mark Dilger <hornschnorter(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Boolean partitions syntax
Date: 2018-03-02 07:27:44
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2018/03/02 15:58, Andres Freund wrote:
> On 2018-02-02 17:00:24 -0500, Tom Lane wrote:
>> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
>>> There might be other options, but one way to solve this would be to
>>> treat partition bounds as a general expression in the grammar and then
>>> check in post-parse analysis that it's a constant.
>> That's pretty much what I said upthread. What I basically don't like
>> about the current setup is that it's assuming that the bound item is
>> a bare literal. Even disregarding future-extension issues, that's bad
>> because it can't result in an error message smarter than "syntax error"
>> when someone tries the rather natural thing of writing a more complicated
>> expression.
> Given the current state of this patch, with a number of senior
> developers disagreeing with the design, and the last CF being in
> progress, I think we should mark this as returned with feedback.

I see no problem with pursuing this in the next CF if the consensus is
that we should fix how partition bounds are parsed, instead of adopting
one of the patches to allow the Boolean literals to be accepted as
partition bounds.

For the latter, my patch [1] would do the job, although after posting that
patch, the discussion turned into the one about the state of the current
partition bound parsing code. I agree with most of the points raised and
Horiguchi-san even came up with a not-so-invasive patch to do that,
although, neither I, nor anyone else has been able to review or test it so
far. I had written a patch like that one myself that I haven't shared on
the list, but had seen some problems with it. I guess I should report
those in reply to Horiguchi-san's post.

That said, after seeing David Rowley's post earlier today [2], it seems
that we may need to consider this issue a bug rather than a new feature.




In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-03-02 07:29:49 Re: [HACKERS] Early locking option to parallel backup
Previous Message Andres Freund 2018-03-02 07:27:09 Re: [HACKERS] log_destination=file