(2017/11/11 0:58), Robert Haas wrote:
On Fri, Nov 10, 2017 at 4:34 AM, Etsuro Fujita
wrote:
Here is a small patch for $Subject.
Good catch. Committed.
Thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
n't
need to ensure those constraints locally. But I'm not sure if the same
thing applies to WCOs on views defined on foreign tables, because in
some case it's not possible to impose constraints on the remote side
that match those WCOs, as I explained before.
Best regards,
Etsuro Fujita
Hi,
Here is a small patch for $Subject.
Best regards,
Etsuro Fujita
*** a/src/backend/optimizer/util/relnode.c
--- b/src/backend/optimizer/util/relnode.c
***
*** 676,683 build_join_rel(PlannerInfo *root,
* 'sjinfo': child-join context info
* 'restric
Hi,
Attached is a patch to reorder header files in joinrels.c and pathnode.c
in alphabetical order, removing unnecessary ones.
Best regards,
Etsuro Fujita
*** a/src/backend/optimizer/path/joinrels.c
--- b/src/backend/optimizer/path/joinrels.c
***
*** 16,30
#include
On 2017/10/30 22:39, Magnus Hagander wrote:
On Mon, Oct 30, 2017 at 3:49 AM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
Here is a patch to fix a typo in a comment in partition.c:
s/specificiation/specification/.
Applied, thanks.
Thank you!
Best regards,
Here is a patch to fix a typo in a comment in partition.c:
s/specificiation/specification/.
Best regards,
Etsuro Fujita
diff --git a/src/backend/catalog/partition.c b/src/backend/catalog/partition.c
index 07fdf66..e234167 100644
--- a/src/backend/catalog/partition.c
+++ b/src/backend/catalog
On 2017/10/28 18:15, Robert Haas wrote:
On Fri, Oct 27, 2017 at 9:34 AM, Etsuro Fujita
wrote:
This sentence in the section of Partition-wise joins in
src/backend/optimizer/README should be fixed: "This technique of breaking
down a join between partition tables into join between
On 2017/10/26 16:40, Etsuro Fujita wrote:
Other changes I made
to the executor are: (1) currently, we set the RT index for the root
partitioned table to ri_RangeTableIndex of partitions' ResultRelInfos,
but the proposed EXPLAIN requires that the partition's
ri_RangeTableIndex is set
in between partitioned tables/
(2) s/join between their partitions/joins between their partitions/
It might be okay to leave #2 as-is, but I'd like to propose to change
that way to make the meaning clear.
Attached is a patch for that.
Best regards,
Etsuro Fujita
diff --git a/src/backend/opt
Hi Maksim,
On 2017/10/02 21:37, Maksim Milyutin wrote:
On 11.09.2017 16:01, Etsuro Fujita wrote:
* Query planning: the patch creates copies of Query/Plan with a
foreign partition as target from the original Query/Plan for each
foreign partition and invokes PlanForeignModify with those copies
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017/10/05 21:48, Robert Haas wrote:
On Thu, Oct 5, 2017 at 6:11 AM, Etsuro Fujita
wrote:
Here is a small patch to fix a typo in a comment in partition.c:
s/mantain/maintain/.
Committed.
Thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Here is a small patch to fix a typo in a comment in partition.c:
s/mantain/maintain/.
Best regards,
Etsuro Fujita
diff --git a/src/backend/catalog/partition.c b/src/backend/catalog/partition.c
index 1ab6dba..9777d40 100644
--- a/src/backend/catalog/partition.c
+++ b/src/backend/catalog
here we ignore what's happening on remote side and enforce
whatever we could enforce locally. Local server should make sure that
any rows sent from local server to the remote server do not violate
any local WCO.
Seems odd (and too restrictive) to me too.
Best regards,
Etsuro Fujita
m ft where a % 4 = 0 with check option;
how is the WCO constraint (ie, a % 4 = 0) ensured remotely, which is
different from the constraint on the foreign table (ie, a % 2 = 0)?
Maybe I'm missing something, though.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-h
27;d propose to fix that by
modifying postgresPlanForeignModify so that it handles WCO the same way
as for the RETURNING case. Attached is a patch for that. I'll add the
patch to the next commitfest.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgre
course to be expected, but we don't
even really have enough bandwidth to deal with the patches that are
being timely updated, never mind the ones that aren't.
Agreed. I marked this as RWF. Thank you.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgs
On 2017/08/17 17:27, Etsuro Fujita wrote:
On 2017/07/11 6:56, Robert Haas wrote:
I have to admit that I'm a little bit fuzzy about why foreign insert
routing requires all of these changes. I think this patch would
benefit from being accompanied by several paragraphs of explanation
outl
On 2017/09/08 0:21, Robert Haas wrote:
On Thu, Sep 7, 2017 at 5:13 AM, Etsuro Fujita
wrote:
On 2017/08/30 17:20, Etsuro Fujita wrote:
Here is a patch to skip the CheckValidResultRel checks for a target table
if it's a foreign partition to perform tuple-routing for, as proposed by
Robert.
On 2017/08/30 17:20, Etsuro Fujita wrote:
Here is a patch to skip the CheckValidResultRel checks for a
target table if it's a foreign partition to perform tuple-routing for,
as proposed by Robert.
In the patch, to skip the checks, I passed to CheckValidResultRel a new
flag indicating wh
On 2017/08/30 17:20, Etsuro Fujita wrote:
On 2017/08/30 9:13, Amit Langote wrote:
On 2017/08/29 20:18, Etsuro Fujita wrote:
On 2017/08/25 22:26, Robert Haas wrote:
On Wed, Aug 23, 2017 at 4:55 AM, Etsuro Fujita
wrote:
Agreed, but I'd vote for fixing this in v10 as proposed; I agree
knows the JOIN system better.
I think Tom is reviewing this patch [1].
Best regards,
Etsuro Fujita
[1] https://www.postgresql.org/message-id/22168.1504041271%40sss.pgh.pa.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ht (c) 1994, Regents of the University of California
Is that intentional?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t contain
respective entries corresponding to the partitioned tables, and
traditionally, the executor looks at those lists to figure out the tables
to lock.
I think so too.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
tioned_rels list from
nodeModifyTable.c.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017/06/21 17:57, Amit Langote wrote:
On 2017/06/21 16:59, Etsuro Fujita wrote:
Commit d3cc37f1d801a6b5cad9bf179274a8d767f1ee50 added this to
ExecInitModifyTable:
+ /* The root table RT index is at the head of the partitioned_rels list */
+ if (node->partitioned_r
ead the patch yet, I think the above code is useless.
And I proposed a patch to clean it up before [1]. I'll add that patch
to the next commitfest.
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message-id/93cf9816-2f7d-0f67-8ed2-4a4e497a6ab8%40lab.ntt.co.jp
--
Sent vi
(I'm not sure we should do the same thing to the function declaration in
other places such as fdwapi.h and the documentation for consistency, but
if so, I'd vote for leaving that for another patch.)
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On 2017/08/26 2:28, Robert Haas wrote:
On Tue, Jul 4, 2017 at 4:55 AM, Etsuro Fujita
wrote:
This comment in an error handling in ExecPartitionCheck():
if (!ExecCheck(resultRelInfo->ri_PartitionCheckExpr, econtext))
{
char *val_desc;
Relationorig_rel =
On 2017/08/26 1:43, Robert Haas wrote:
On Sun, Aug 20, 2017 at 11:25 PM, Etsuro Fujita
wrote:
I agree, but I wonder if we ought to make it work first using the
existing APIs and then add these new APIs as an optimization.
I'm not sure that's a good idea because that once we supp
On 2017/08/30 9:13, Amit Langote wrote:
On 2017/08/29 20:18, Etsuro Fujita wrote:
On 2017/08/25 22:26, Robert Haas wrote:
On Wed, Aug 23, 2017 at 4:55 AM, Etsuro Fujita
wrote:
Agreed, but I'd vote for fixing this in v10 as proposed; I agree that just
ripping the CheckValidResultRel c
On 2017/08/25 22:26, Robert Haas wrote:
On Wed, Aug 23, 2017 at 4:55 AM, Etsuro Fujita
wrote:
Agreed, but I'd vote for fixing this in v10 as proposed; I agree that just
ripping the CheckValidResultRel checks out entirely is not a good idea, but
that seems OK to me at least as a fix jus
On 2017/08/21 20:37, Etsuro Fujita wrote:
Attached is an updated version of the patch.
I corrected some comments. New version attached.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/expected/postgres_fdw.out
--- b/contrib/postgres_fdw/expected/postgres_fdw.out
On 2017/08/22 9:55, Amit Langote wrote:
On 2017/08/22 1:08, Robert Haas wrote:
On Mon, Aug 21, 2017 at 7:45 AM, Etsuro Fujita
wrote:
If there are no objections, I'll add this to the open item list for v10.
This seems fairly ad-hoc to me. I mean, now you have
CheckValidResultRel not
On 2017/08/07 15:45, Etsuro Fujita wrote:
On 2017/08/07 15:33, Amit Langote wrote:
On 2017/08/07 15:22, Etsuro Fujita wrote:
On 2017/08/07 13:11, Amit Langote wrote:> The patch looks good too.
Although, looking at the following hunk:
+ Assert(partrel->rd_rel-&g
a bug fix, so I dropped that. (I'll propose that as part of the
patch in [1].)
There's probably more to think about here, but those are my question
on an initial read-through.
Thanks for the review!
Attached is an updated version of the patch.
Best regards,
Etsuro Fujita
[1] https:
back-patched the proposed patch.
Thanks.
Thank you!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017/08/19 2:12, Robert Haas wrote:
On Thu, Aug 17, 2017 at 4:27 AM, Etsuro Fujita
wrote:
I think that would be much more efficient than INSERTing tuples into the
remote server one by one. What do you think about that?
I agree, but I wonder if we ought to make it work first using the
On 2017/08/18 22:41, David Fetter wrote:
On Fri, Aug 18, 2017 at 05:10:29PM +0900, Etsuro Fujita wrote:
On 2017/08/17 23:48, David Fetter wrote:
On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote:
On 2017/07/11 6:56, Robert Haas wrote:
On Thu, Jun 29, 2017 at 6:20 AM, Etsuro
On 2017/08/17 23:48, David Fetter wrote:
On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote:
On 2017/07/11 6:56, Robert Haas wrote:
On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita
wrote:
So, I dropped the COPY part.
Ouch. I think we should try to figure out how the COPY part
On 2017/08/18 8:16, Michael Paquier wrote:
On Fri, Aug 18, 2017 at 3:59 AM, Tom Lane wrote:
Robert Haas writes:
On Thu, Aug 17, 2017 at 8:00 AM, Etsuro Fujita
wrote:
I rebased the patch to HEAD. PFA a new version of the patch.
Tom, you were instrumental in identifying what was going
tch for addressing the
GetExistingLocalJoinPath issue [1].
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message-id/6008ca34-906f-e61d-478b-8f85fde2c090%40lab.ntt.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On 2017/04/04 18:01, Etsuro Fujita wrote:
I rebased the patch also. Please find attached an updated version of
the patch.
I rebased the patch to HEAD. PFA a new version of the patch.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/expected/postgres_fdw.out
--- b/contrib/postgres_fdw
On 2017/08/17 20:37, Ashutosh Bapat wrote:
On Thu, Aug 17, 2017 at 1:57 PM, Etsuro Fujita
wrote:
I spent some time on this. To handle that, I'd like to propose doing
something similar to \copy (frontend copy): submit a COPY query "COPY ...
FROM STDIN" to the remote server and
On 2017/07/11 6:56, Robert Haas wrote:
On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita
wrote:
So, I dropped the COPY part.
Ouch. I think we should try to figure out how the COPY part will be
handled before we commit to a design.
I spent some time on this. To handle that, I'd li
XPLAIN ANALYZE might produce odd outputs), so I modified
ExecGetTriggerResultRel so that it searches es_leaf_result_relations and
es_root_result_relations in addition to es_result_relations.
Best regards,
Etsuro Fujita
*** a/src/backend/commands/copy.c
--- b/src/backend/commands/copy.c
***
On 2017/08/11 2:18, Robert Haas wrote:
On Thu, Aug 10, 2017 at 8:25 AM, Etsuro Fujita
wrote:
Here is a small patch for fixing a comment typo in plannodes.h: s/all the
partitioned table/all the partitioned tables/.
Committed.
Thank you.
Best regards,
Etsuro Fujita
--
Sent via pgsql
Hi,
Here is a small patch for fixing a comment typo in plannodes.h: s/all
the partitioned table/all the partitioned tables/.
Best regards,
Etsuro Fujita
diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h
index f1a1b24..7c51e7f 100644
--- a/src/include/nodes/plannodes.h
On 2017/08/07 15:33, Amit Langote wrote:
On 2017/08/07 15:22, Etsuro Fujita wrote:
On 2017/08/07 13:11, Amit Langote wrote:> The patch looks good too.
Although, looking at the following hunk:
+ Assert(partrel->rd_rel->relkind == RELKIND_RELATION ||
+partre
here is a new version which removes the verification at all from
ExecSetupPartitionTupleRouting.
Best regards,
Etsuro Fujita
*** /dev/null
--- b/contrib/file_fdw/data/list1.csv
***
*** 0
--- 1,2
+ 1,foo
+ 1,bar
*** /dev/null
--- b/contrib/file_fdw/data/list2.bad
*
ine is not NULL. Attached is a proposed patch
for that. Since COPY FROM has the same issue, I added regression tests
for COPY FROM as well as INSERT to file_fdw.
Best regards,
Etsuro Fujita
*** /dev/null
--- b/contrib/file_fdw/data/list1.csv
***
*** 0
--- 1,2
+ 1,foo
+ 1
On 2017/08/04 1:52, Robert Haas wrote:
On Thu, Aug 3, 2017 at 5:55 AM, Etsuro Fujita
wrote:
I updated the patch that way. Attached is a new version of the patch.
Committed.
Thanks again.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 2017/08/04 10:00, Amit Langote wrote:
On 2017/08/04 1:06, Robert Haas wrote:
On Thu, Aug 3, 2017 at 4:40 AM, Etsuro Fujita
wrote:
On 2017/08/03 17:12, Amit Langote wrote:
Attached updated patches.
Thanks for the patch! That looks good to me.
Committed with some comment changes
On 2017/08/02 4:07, Robert Haas wrote:
On Tue, Aug 1, 2017 at 12:31 AM, Etsuro Fujita
wrote:
Maybe I'm missing something, but I'm not sure that's a good idea because the
change says like we might have 'wholerow' only for the FDW case, but that
isn't correct becaus
On 2017/08/03 17:12, Amit Langote wrote:
Attached updated patches.
Thanks for the patch! That looks good to me.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On 2017/08/02 15:21, Amit Langote wrote:
Thanks Fuita-san and Amit for reviewing.
On 2017/08/02 1:33, Amit Khandekar wrote:
On 1 August 2017 at 15:11, Etsuro Fujita wrote:
On 2017/07/31 18:56, Amit Langote wrote:
Yes, that's what's needed here. So we nee
?
I'll take another look at the patch from now.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017/08/01 6:09, Peter Eisentraut wrote:
On 7/6/17 03:23, Etsuro Fujita wrote:
Here is a comment in ExecFindPartition() in execMain.c:
/*
* First check the root table's partition constraint, if any. No
point in
* routing the tuple it if it doesn't belong i
newvar->vartype = context->to_rowtype;
+ return (Node *) r;
+ }
I think we could set r->resulttype to the vartype (ie, "r->resulttype =
newvar->vartype" instead of "r->resulttype =
On 2017/08/01 1:03, Robert Haas wrote:
On Fri, Jul 28, 2017 at 8:12 AM, Etsuro Fujita
wrote:
On 2017/07/26 22:39, Robert Haas wrote:
So the first part of the change weakens the assertion that a 'ctid' or
'wholerow' attribute will always be present by saying that an FDW ma
constraints?
Other than that, the patch looks good to me.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017/07/26 22:39, Robert Haas wrote:
On Wed, Jun 14, 2017 at 10:40 PM, Etsuro Fujita
wrote:
Attached is an updated version of the patch.
Well, now I'm confused:
* Initialize the junk filter(s) if needed. INSERT queries need a filter
* if there are any junk attrs i
along with the traditional constraints such as
NOT NULL and CHECK constraints, which we can do for local table partitions
but not for foreign table ones.
Anyway, attached patch documents all these limitations about foreign table
partitions more prominently.
Typo: s/the they is/they are/
Best regards,
Etsur
right place in the order, but
there will be lots of cases where it can work).
+1 for that as well. Another benefit from that would be EXPLAIN; we
could display partitions for a partitioned table in the same order for
Append and ModifyTable (ie, SELECT/UPDATE/DELETE), which I think would
make the E
On 2017/07/25 5:35, Robert Haas wrote:
On Fri, Jul 21, 2017 at 6:21 AM, Etsuro Fujita
wrote:
I mean constraints derived from WITH CHECK OPTIONs specified for parent
views. We use the words "WITH CHECK OPTION constraints" in comments in
nodeModifyTable.c, so the expression &qu
do_convert_tuple() in
that function, again without changing the slot descriptor.
Yeah, I think we would need that in ExecPartitionCheck() as well.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 2017/07/21 19:16, Etsuro Fujita wrote:
On 2017/07/20 11:21, Etsuro Fujita wrote:
On 2017/07/19 23:36, Tom Lane wrote:
Please put the responsibility of doing const-expression simplification
in these cases somewhere closer to where the problem is being created.
It would be reasonable that
On 2017/07/21 17:18, Kyotaro HORIGUCHI wrote:
At Fri, 21 Jul 2017 12:00:03 +0900, Etsuro Fujita wrote
in <15aa9936-9bd8-c9e3-7ca1-394861073...@lab.ntt.co.jp>
Attached is the second version which updated docs in postgres-fdw.sgml
as well.
!no local joins for the query, no row-level
On 2017/07/20 11:21, Etsuro Fujita wrote:
On 2017/07/19 23:36, Tom Lane wrote:
Please put the responsibility of doing const-expression simplification
in these cases somewhere closer to where the problem is being created.
It would be reasonable that it's the FDW's responsibility
On 2017/07/21 3:24, Robert Haas wrote:
I think that's reasonable. This should be committed and back-patched
to 9.6, right?
Yeah, because direct modify was introduced in 9.6.
Attached is the second version which updated docs in postgres-fdw.sgml
as well.
Best regards,
Etsuro Fujita
x this by just giving up direct modify if there are
any WITH CHECK OPTIONs. Attached is a patch for that. I'll add it to
the next commitfest.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/expected/postgres_fdw.out
--- b/contrib/postgres_fdw/expected/postgres_fdw.out
On 2017/07/19 23:36, Tom Lane wrote:
Etsuro Fujita writes:
* Modified rewrite_targetlist(), which is a new function added to
preptlist.c, so that we do const-simplification to junk TLEs that
AddForeignUpdateTargets() added, as that API allows the FDW to add junk
TLEs containing non-Var
On 2017/07/13 21:10, Etsuro Fujita wrote:
Attached is an updated version of the patch.
Here is an updated version of the patch. Changes are:
* Modified rewrite_targetlist(), which is a new function added to
preptlist.c, so that we do const-simplification to junk TLEs that
On 2017/07/18 11:03, Robert Haas wrote:
On Mon, Jul 10, 2017 at 5:44 PM, Robert Haas wrote:
The posted patches look OK to me. Barring developments, I will commit
them on 2017-07-17, or send another update by then.
Committed them.
Thank you!
Best regards,
Etsuro Fujita
--
Sent via
On 2017/06/30 18:44, Etsuro Fujita wrote:
On 2017/06/16 21:29, Etsuro Fujita wrote:
I'll have second thought about this, so I'll mark this as waiting on
author.
I spent quite a bit of time on this and came up with a solution for
addressing the concern mentioned by Ashutosh [1].
On 2017/07/07 18:47, Amit Langote wrote:
On 2017/07/06 16:06, Etsuro Fujita wrote:
I think this should be fixed. Attached is a patch for that.
Looking up the ResultRelInfo using the proposed method in
ExecFindResultRelInfo() can be unreliable sometimes, that is, the method
of using the root
On 2017/07/05 9:13, Amit Langote wrote:
On 2017/06/29 20:20, Etsuro Fujita wrote:
In relation to this, I also allowed expand_inherited_rtentry() to
build an RTE and AppendRelInfo for each partition of a partitioned table
that is an INSERT target, as mentioned by Amit in [1], by modifying
efore "if" is a typo.
Attached is a small patch for fixing that.
Best regards,
Etsuro Fujita
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 0f08283..06b467b 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -3310,
re the partitioned table isn't the
primary ModifyTable node*, which leads to deriving an incorrect
modifiedCols and then invoking ExecBuildSlotValueDescription with the
wrong bitmap. I think this should be fixed. Attached is a patch for that.
Best regards,
Etsuro Fujita
*** a/src/backend/e
On 2017/07/04 18:15, Amit Langote wrote:
On 2017/07/04 17:55, Etsuro Fujita wrote:
This comment in an error handling in ExecPartitionCheck():
if (!ExecCheck(resultRelInfo->ri_PartitionCheckExpr, econtext))
{
char *val_desc;
Relationorig_rel =
that.
Best regards,
Etsuro Fujita
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 0f08283..dcf685a 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -1864,7 +1864,7 @@ ExecPartitionCheck(ResultRelInfo *resultRelInfo,
Is anyone working on that?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017/06/16 21:29, Etsuro Fujita wrote:
On 2017/06/16 19:26, Ashutosh Bapat wrote:
That issue has not been addressed. The reason stated was that it would
make code complicated. But I have not had chance to look at how
complicated would be and assess myself whether that's worth the
tr
Hi Maksim,
On 2017/04/07 19:52, Maksim Milyutin wrote:
On 07.04.2017 13:05, Etsuro Fujita wrote:
On 2016/12/09 19:46, Maksim Milyutin wrote:
I would like to work on two tasks:
- insert (and eventually update) tuple routing for foreign partition.
- the ability to create an index on the
ote SQL: INSERT INTO public.t1(a) VALUES ($1)
Foreign Insert on public.fp2
Remote SQL: INSERT INTO public.t2(a) VALUES ($1)
-> Values Scan on "*VALUES*" (cost=0.00..0.03 rows=2 width=4)
Output: "*VALUES*".column1
(7 rows)
Comments are welcome! Anyw
On 2017/06/23 2:53, Robert Haas wrote:
On Thu, Jun 15, 2017 at 4:40 AM, Etsuro Fujita
wrote:
While working on adding support for tuple routing for foreign partitions, I
noticed that in create_modifytable_path, we forgot to add a comment on its
new argument 'partitioned_rels'. Attach
ition tree */
List *partitioned_rels;
I agree on that point, but I think it's better to add the missing
comment for the create_modifytable_path argument, as proposed in [1].
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message-id/e87c4a6d-23d7-5e7c-e8db-44ed418eb5d1%
Here is a patch to fix a typo in a comment in ExecWithCheckOptions():
s/as as/as/.
Best regards,
Etsuro Fujita
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 7f460bd..9dbe175 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
'd like to
propose to remove this from that function. Attached is a patch for that.
Best regards,
Etsuro Fujita
*** a/src/backend/executor/nodeModifyTable.c
--- b/src/backend/executor/nodeModifyTable.c
***
*** 45,51
#include "foreign/fdwapi.h"
#include "
On 2017/06/21 3:30, Peter Eisentraut wrote:
On 6/20/17 05:50, Etsuro Fujita wrote:
Here is a small patch to add a comment on its new member PartitionRoot.
The existing comment style is kind of unusual. How about the attached
to clean it up a bit?
+1 for that change.
Best regards,
Etsuro
Here is a small patch to add a comment on its new member PartitionRoot.
Best regards,
Etsuro Fujita
diff --git a/src/include/nodes/execnodes.h b/src/include/nodes/execnodes.h
index d33392f..7175a42 100644
--- a/src/include/nodes/execnodes.h
+++ b/src/include/nodes/execnodes.h
@@ -365,6 +365,7
On 2017/06/16 19:26, Ashutosh Bapat wrote:
On Fri, Jun 16, 2017 at 3:35 PM, Etsuro Fujita
Ashutosh mentioned his concern about what I proposed above before [2], but
I'm not sure we should address that. And there have been no opinions from
him (or anyone else) since then. So, I'd lik
have different foreign servers
with different FDWs since it applies rewriteTargetListUD to each child
table when generating a modified query with that child table with the
target in inheritance_planner. I didn't any regression tests for that,
though.
Best regards,
Etsuro Fujita
-
g code in prepunion.c
and revised some comments a bit. I didn't make any functional changes,
so I'll keep this Ready for Committer.
Best regards,
Etsuro Fujita
[2]
https://www.postgresql.org/message-id/CAFjFpRfTpamoUz6fNyk6gPh%3DecfBJjbUHJNKbDxscpyPJ3FfjQ%40mail.gmail.com
*** a/
While working on adding support for tuple routing for foreign
partitions, I noticed that in create_modifytable_path, we forgot to add
a comment on its new argument 'partitioned_rels'. Attached a patch for
including that in the comments for that function.
Best regards,
Etsuro F
On 2017/06/07 0:30, Robert Haas wrote:
On Mon, Jun 5, 2017 at 4:45 AM, Etsuro Fujita
wrote:
While working on [1], I noticed that the comment in ExecModifyTable:
* Foreign table updates have a wholerow attribute when the
* relation has an AFTER ROW trigger
On 2017/06/05 17:39, Ashutosh Bapat wrote:
On Fri, Jun 2, 2017 at 2:40 PM, Etsuro Fujita
While updating the patch, I noticed the patch rewrites the UPDATE targetList
incorrectly in some cases; rewrite_inherited_tlist I added to
adjust_appendrel_attrs (1) removes all junk items from the
AFTER ROW or BEFORE ROW trigger (see
rewriteTargetListUD). So I'd propose s/an AFTER ROW trigger/a row-level
trigger/. Attached is a patch for that.
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message-id/a31f779e-9cb8-1ea5-71a6-bca6adbfa6a4%40lab.ntt.co.jp
diff --git
On 2017/06/02 18:10, Etsuro Fujita wrote:
On 2017/05/16 21:36, Etsuro Fujita wrote:
One approach I came up with to fix this issue is to rewrite the
targetList entries of an inherited UPDATE/DELETE properly using
rewriteTargetListUD, when generating a plan for each child table in
On 2017/05/16 21:36, Etsuro Fujita wrote:
One approach I came up with to fix this issue is to rewrite the
targetList entries of an inherited UPDATE/DELETE properly using
rewriteTargetListUD, when generating a plan for each child table in
inheritance_planner. Attached is a WIP patch for that
1 - 100 of 967 matches
Mail list logo
