On 2019/03/28 21:14, Michael Paquier wrote:
> On Wed, Mar 27, 2019 at 12:13:16PM +0900, Michael Paquier wrote:
>> ParseExprKind is an enum, so listing all the options without the
>> default has the advantage to generate a warning if somebody adds a
>> value. This way anybody changing this code wil
On Wed, Mar 27, 2019 at 12:13:16PM +0900, Michael Paquier wrote:
> ParseExprKind is an enum, so listing all the options without the
> default has the advantage to generate a warning if somebody adds a
> value. This way anybody changing this code will need to think about
> it.
A bit late, but comm
On Tue, Mar 26, 2019 at 10:03:35AM -0400, Tom Lane wrote:
> +1 for the general idea, but I find the switch a bit overly verbose.
> Do we really need to force every new EXPR_KIND to visit this spot,
> when so few of them have a need to do anything? I'd be a bit inclined
> to simplify it to
>
>
Michael Paquier writes:
> One idea which came from Amit, and it seems to me that it is a good
> idea, would be to have more context-related error messages directly in
> transformColumnRef(), so as we can discard at an early stage column
> references which are part of contexts where there is no mea
Hi all,
I have just committed a fix for a crash with the handling of partition
bounds using column references which has been discussed here:
https://www.postgresql.org/message-id/15668-0377b1981aa1a...@postgresql.org
And while discussing on the matter with Amit, the point has been
raised that def
