On Tue, Sep 29, 2020 at 2:01 AM Tom Lane wrote:
> Amit Langote writes:
> > On Fri, Sep 25, 2020 at 12:02 AM Tom Lane wrote:
> >> Well, I agree with Peter to that extent, but my opinion is that *none*
> >> of these cases ought to be errors. What we're doing here is performing
> >> an implicit
Amit Langote writes:
> On Fri, Sep 25, 2020 at 12:02 AM Tom Lane wrote:
>> Well, I agree with Peter to that extent, but my opinion is that *none*
>> of these cases ought to be errors. What we're doing here is performing
>> an implicit assignment-level coercion of the expression to the type of
On Fri, Sep 25, 2020 at 12:02 AM Tom Lane wrote:
> [ cc'ing Peter, since his opinion seems to have got us here in the first
> place ]
>
> Amit Langote writes:
> > On Thu, Sep 24, 2020 at 7:19 AM Tom Lane wrote:
> >> However, while I was looking at it I couldn't help noticing that
> >>
[ cc'ing Peter, since his opinion seems to have got us here in the first place ]
Amit Langote writes:
> On Thu, Sep 24, 2020 at 7:19 AM Tom Lane wrote:
>> However, while I was looking at it I couldn't help noticing that
>> transformPartitionBoundValue's handling of collation concerns seems
>>
On Thu, Sep 24, 2020 at 7:19 AM Tom Lane wrote:
> I looked this over and pushed it with some minor adjustments.
Thank you.
> However, while I was looking at it I couldn't help noticing that
> transformPartitionBoundValue's handling of collation concerns seems
> less than sane. There are two
I looked this over and pushed it with some minor adjustments.
However, while I was looking at it I couldn't help noticing that
transformPartitionBoundValue's handling of collation concerns seems
less than sane. There are two things bugging me:
1. Why does it care about the expression's
On Wed, Sep 23, 2020 at 10:22 PM Ashutosh Bapat
wrote:
> On Wed, 23 Sep 2020 at 14:41, Amit Langote wrote:
> Setting this CF entry as "RFC". Thanks.
Great, thanks for your time on this.
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
On Wed, 23 Sep 2020 at 14:41, Amit Langote wrote:
> Thanks Ashutosh.
>
> On Fri, Sep 18, 2020 at 7:33 PM Ashutosh Bapat
> wrote:
> > Thanks Amit for addressing comments.
> >
> > @@ -4256,5 +4256,8 @@ transformPartitionBoundValue(ParseState *pstate,
> Node *val,
> > if (!IsA(value, Const))
> >
Thanks Ashutosh.
On Fri, Sep 18, 2020 at 7:33 PM Ashutosh Bapat
wrote:
> Thanks Amit for addressing comments.
>
> @@ -4256,5 +4256,8 @@ transformPartitionBoundValue(ParseState *pstate, Node
> *val,
> if (!IsA(value, Const))
> elog(ERROR, "could not evaluate partition bound expression");
>
>
On Thu, 17 Sep 2020 at 13:06, Amit Langote wrote:
> Hi Ashutosh,
>
> I had forgotten about this thread, but Michael's ping email brought it
> to my attention.
>
> Thanks Amit for addressing comments.
@@ -4256,5 +4256,8 @@ transformPartitionBoundValue(ParseState *pstate, Node
*val,
if
Hi Ashutosh,
I had forgotten about this thread, but Michael's ping email brought it
to my attention.
On Fri, Sep 4, 2020 at 11:12 PM Ashutosh Bapat
wrote:
> Thanks for rebasing patch. It applies cleanly still. Here are some comments
Thanks for the review.
> @@ -3320,7 +3338,9 @@
On Fri, Sep 04, 2020 at 07:42:27PM +0530, Ashutosh Bapat wrote:
> After this change, the patch will be ready for a committer.
Alexandra, this patch is waiting on author after this review. Could
you answer to the points raised by Ashutosh and update this patch
accordingly?
--
Michael
On Fri, 10 Jul 2020 at 23:31, Alexandra Wang
wrote:
>
>
> Thank you Daniel. Here's the rebased patch. I also squashed the two
> patches into one so it's easier to review.
>
> Thanks for rebasing patch. It applies cleanly still. Here are some comments
@@ -3320,7 +3338,9 @@
to review.
--
Alex
From 334bb4ea93448073778930201c0b959c5acab924 Mon Sep 17 00:00:00 2001
From: Alexandra Wang
Date: Mon, 13 Jul 2020 10:28:04 -0700
Subject: [PATCH] Improve check new partition bound error position report
We have been passing a dummy ParseState to ereport(). Without the s
squashed the two
patches into one so it's easier to review.
--
*Alexandra Wang*
From 572f9086fc9d6e3e7cf1e58c3a6ee21dd8cd9f1b Mon Sep 17 00:00:00 2001
From: Alexandra Wang
Date: Fri, 10 Jul 2020 10:28:49 -0700
Subject: [PATCH] Improve check new partition bound error position report
We have been passing a dummy ParseState to ereport(
> On 10 Apr 2020, at 23:50, Alexandra Wang wrote:
> On Fri, Apr 10, 2020 at 8:37 AM Ashutosh Bapat
> mailto:ashutosh.ba...@2ndquadrant.com>>
> wrote:
> > for a multi-key value the ^
> > points to the first column and the reader may think that that's the
> > problematci column. Should it
to also report the exact column
for the partition overlap errors.
From f7cf86fcf7c1a26895e68f357717244f776fe5cd Mon Sep 17 00:00:00 2001
From: Alexandra Wang
Date: Fri, 10 Apr 2020 13:51:53 -0700
Subject: [PATCH v2] Improve check new partition bound error position report
---
src/backend/parser/
On Fri, 10 Apr 2020 at 14:31, Amit Langote wrote:
> I agree with that. Tried that in the attached 0002, although trying
> to get the cursor to point to exactly the offending column seems a bit
> tough for partition overlap errors. The patch does allow to single
> out which one of the lower and
On Fri, 10 Apr 2020 at 14:31, Amit Langote wrote:
> On Thu, Apr 9, 2020 at 11:04 PM Tom Lane wrote:
> > While I'm quite on board with providing useful error cursors,
> > the example cases in this patch don't seem all that useful:
> >
> > -- trying to create range partition with empty range
> >
On Thu, Apr 9, 2020 at 11:04 PM Tom Lane wrote:
> While I'm quite on board with providing useful error cursors,
> the example cases in this patch don't seem all that useful:
>
> -- trying to create range partition with empty range
> CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES
On Thu, Apr 9, 2020 at 10:51 PM Ashutosh Bapat
wrote:
>
> Hi Alexandra,
> As Michael said it will be considered for the next commitfest. But
> from a quick glance, a suggestion.
> Instead of passing NULL parsestate from ATExecAttachPartition, pass
> make_parsestate(NULL). parse_errorposition()
While I'm quite on board with providing useful error cursors,
the example cases in this patch don't seem all that useful:
-- trying to create range partition with empty range
CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES FROM (1) TO (0);
ERROR: empty range bound specified for
Hi Alexandra,
As Michael said it will be considered for the next commitfest. But
from a quick glance, a suggestion.
Instead of passing NULL parsestate from ATExecAttachPartition, pass
make_parsestate(NULL). parse_errorposition() takes care of NULL parse
state input, but it might be safer this way.
On Wed, Apr 08, 2020 at 08:17:55PM -0700, Alexandra Wang wrote:
> On Wed, Apr 8, 2020 at 6:11 PM Michael Paquier wrote:
> > Please note that you forgot to update the regression test output.
>
> Yep thanks! Please see my previous email for the updated patch.
Thanks, I saw the update. It looks
On Wed, Apr 8, 2020 at 6:11 PM Michael Paquier wrote:
> Please note that you forgot to update the regression test output.
Yep thanks! Please see my previous email for the updated patch.
On Wed, Apr 08, 2020 at 05:15:57PM -0700, Alexandra Wang wrote:
> I have attached a patch to pass in a ParseState to
> check_new_partition_bound() to enable the reporting of the error
> position. Below is what the error message looks like before and after
> applying the patch.
>
> Another option
Forgot to run make installcheck. Here's the new version of the patch that
updated the test answer file.
From 9071918648412383e41976a01106257bd6a2539e Mon Sep 17 00:00:00 2001
From: Alexandra Wang
Date: Wed, 8 Apr 2020 16:07:28 -0700
Subject: [PATCH v2] Report error position in partition bound
ument at all
to ereport() in this function, since the query is relatively short and
the error message is already descriptive enough.
Alex and Ashwin
From b1aedddaf7ae0f609910ff82af136d93c0132c2e Mon Sep 17 00:00:00 2001
From: Alexandra Wang
Date: Wed, 8 Apr 2020 16:07:28 -0700
Subject: [PATCH
28 matches
Mail list logo
