Re: Misleading errors with column references in default expressions and partition bounds

2019-03-28 Thread Amit Langote
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

Re: Misleading errors with column references in default expressions and partition bounds

2019-03-28 Thread Michael Paquier
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

Re: Misleading errors with column references in default expressions and partition bounds

2019-03-26 Thread Michael Paquier
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 > >

Re: Misleading errors with column references in default expressions and partition bounds

2019-03-26 Thread Tom Lane
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