Hi,
On 2019/03/26 10:15, Michael Paquier wrote:
> Done as you suggested, with a minimal set enough to trigger the crash,
> still the error message is rather misleading as you would expect :)
Thanks for committing.
>> A separate thread will definitely attract more attention, at least in due
>>
On Fri, Mar 22, 2019 at 02:49:42PM +0900, Amit Langote wrote:
> This comment sounds a bit misleading. The code above this "did" find
> field names, but there were too many. What this comment should mention is
> that parsing didn't return a single field name, which is the format that
> the code
Hi,
Thanks for splitting. It makes sense, because, as you know, the bug that
causes the crash is a separate problem from unintuitive error messages
which result from the way in which we parse expressions.
On 2019/03/22 14:09, Michael Paquier wrote:
> On Wed, Mar 20, 2019 at 06:17:27PM +0900,
On Wed, Mar 20, 2019 at 06:17:27PM +0900, Michael Paquier wrote:
> The thing is that in order to keep the tests for the crash, we finish
> with the inintuitive RTE-related errors, so it is also inconsistent to
> not group things..
As I have seen no feedback from others regarding the changes in
On Wed, Mar 20, 2019 at 06:07:23PM +0900, Amit Langote wrote:
> because we can notice the aggregate before we look into its arguments.
> Maybe, we should move the error-checking switch to a point before checking
> the arguments? That looks slightly more drastic change to make though.
Yeah, I
Hi,
On 2019/03/20 11:07, Michael Paquier wrote:
> On Thu, Mar 14, 2019 at 01:23:08PM +0900, Michael Paquier wrote:
>> I actually think that what you propose here makes more sense than what
>> HEAD does because the most inner expression gets evaluated first.
>> This for example generates the same
On Thu, Mar 14, 2019 at 01:23:08PM +0900, Michael Paquier wrote:
> I actually think that what you propose here makes more sense than what
> HEAD does because the most inner expression gets evaluated first.
> This for example generates the same error as on HEAD:
> =# create table foo (a int default
On Wed, Mar 13, 2019 at 03:17:47PM +0900, Amit Langote wrote:
> but on HEAD, you get:
>
> create table foo (a int default (avg(foo.a)));
> ERROR: aggregate functions are not allowed in DEFAULT expressions
I actually think that what you propose here makes more sense than what
HEAD does because
On 2019/03/13 14:15, Amit Langote wrote:
> On 2019/03/11 16:21, Michael Paquier wrote:
>> On Mon, Mar 11, 2019 at 03:44:39PM +0900, Amit Langote wrote:
>>> We could make the error message more meaningful depending on the context,
>>> but maybe it'd better be pursue it as a separate project.
>>
>>
On 2019/03/11 16:21, Michael Paquier wrote:
> On Mon, Mar 11, 2019 at 03:44:39PM +0900, Amit Langote wrote:
>> We could make the error message more meaningful depending on the context,
>> but maybe it'd better be pursue it as a separate project.
>
> Yeah, I noticed that stuff when working on it
On 2019/03/13 1:35, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 11, 2019 at 2:45 AM Amit Langote
>> wrote:
>>> I noticed another issue with the code -- it's using strcmp() to compare
>>> specified string against "minvalue" and "maxvalue", which causes the
>>> following silly error:
>>>
Robert Haas writes:
> On Mon, Mar 11, 2019 at 2:45 AM Amit Langote
> wrote:
>> I noticed another issue with the code -- it's using strcmp() to compare
>> specified string against "minvalue" and "maxvalue", which causes the
>> following silly error:
>>
>> create table q2 partition of q for
On Mon, Mar 11, 2019 at 2:45 AM Amit Langote
wrote:
> I noticed another issue with the code -- it's using strcmp() to compare
> specified string against "minvalue" and "maxvalue", which causes the
> following silly error:
>
> create table q2 partition of q for values from ("MINVALUE") to
On Mon, Mar 11, 2019 at 03:44:39PM +0900, Amit Langote wrote:
> We could make the error message more meaningful depending on the context,
> but maybe it'd better be pursue it as a separate project.
Yeah, I noticed that stuff when working on it this afternoon. The
error message does not
Hi,
On 2019/03/06 17:27, Michael Paquier wrote:
> On Wed, Mar 06, 2019 at 04:00:42PM +0900, Amit Langote wrote:
>> Thanks for looking at this. Your patch seems better, because it allows us
>> to keep the error message consistent with the message one would get with
>> list-partitioned syntax.
>
On Wed, Mar 06, 2019 at 04:00:42PM +0900, Amit Langote wrote:
> Thanks for looking at this. Your patch seems better, because it allows us
> to keep the error message consistent with the message one would get with
> list-partitioned syntax.
Thanks for confirming. I think that it would be nice as
Hi,
On 2019/03/06 15:48, Michael Paquier wrote:
> On Tue, Mar 05, 2019 at 11:04:17PM +0900, Amit Langote wrote:
>> Maybe we should error out as follows in
>> transformPartitionRangeBounds(), although that means we'll get
>> different error message than when using list partitioning syntax:
>
>
On Tue, Mar 05, 2019 at 11:04:17PM +0900, Amit Langote wrote:
> Maybe we should error out as follows in
> transformPartitionRangeBounds(), although that means we'll get
> different error message than when using list partitioning syntax:
Hm. I don't think that this is a good idea as you could
Hi,
(cc'ing -hackers and Peter E)
On Tue, Mar 5, 2019 at 8:02 PM PG Bug reporting form
wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 15668
> Logged by: Alexander Lakhin
> Email address: exclus...@gmail.com
> PostgreSQL version:
19 matches
Mail list logo
