evising the patch that I created for
that. If it's okay, I'd like to propose an updated version of the patch
in a few days.
> I cannot understand why Fujita-san never "try" this approach.
Maybe my explanation was not correct, but I didn't say such a thing.
What I ra
the added break is in the added curly-braces but
it would be better to place it after the closing brace, like the
other cases.
Changed that, and committed.
Thanks, Robert and Horiguchi-san.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
ssumed to be handled in the callback routine to be kicked from
> ForeignRecheck().
Honestly, I still don't think I would see the much value in doing so.
As Robert mentioned in [1], I think that if we're inside EPQ,
pushed-down quals and/or pushed-down joins should be locally rechecke
On 2015/10/14 17:31, Etsuro Fujita wrote:
As KaiGai-san also pointed out before, I think we should address this in
each of the following cases:
1) remote qual (scanrelid>0)
2) remote join (scanrelid==0)
As for #2, I updated the patch, which uses a local join execution plan
for
On 2015/10/17 12:22, Robert Haas wrote:
On Fri, Oct 16, 2015 at 9:51 PM, Tom Lane wrote:
Robert Haas writes:
Both you and Etsuro Fujita are proposing to fix this problem by
somehow making it the FDW's problem to reconstruct the tuple
previously produced by the join from whole-row imag
the pushed-down join looks at
its EPQ slot, I think the plan can return at most one tuple.
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 and add a bit more comments
Thanks for the comments!
Best regards,
Etsuro Fujita
*** a/contrib/file_fdw/file_fdw.c
--- b/contrib/file_fdw/file_fdw.c
***
*** 525,530 fileGetForeignPaths(PlannerInfo *root,
--- 525,531
total_cost,
NIL, /* no pathkeys
>
> I don't think it is a good interface design to enforce people to
> follow a particular implementation manner. It should be discretion
> of the extension.
I think that if you think so, you should give at least one concrete
example for that. Ideally accompanied by a demo of ho
On 2015/10/20 5:34, Robert Haas wrote:
On Mon, Oct 19, 2015 at 3:45 AM, Etsuro Fujita
wrote:
As Tom mentioned, just recomputing the original join tuple is not good
enough. We would need to rejoin the test tuples for the baserels even if
ROW_MARK_COPY is in use. Consider:
A=# BEGIN;
A
On Mon, Oct 19, 2015 at 3:45 AM, Etsuro Fujita
wrote:
As Tom mentioned, just recomputing the original join tuple is not good
enough. We would need to rejoin the test tuples for the baserels even if
ROW_MARK_COPY is in use. Consider:
A=# BEGIN;
A=# UPDATE t SET a = a + 1 WHERE b = 1;
B
Hi,
I found typos in plannodes.h: s/scan.plan.quals/scan.plan.qual/g Please
find attached a patch.
Best regards,
Etsuro Fujita
diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h
index 92fd8e4..6b28c8e 100644
--- a/src/include/nodes/plannodes.h
+++ b/src/include/nodes
On 2015/10/21 0:13, Robert Haas wrote:
On Tue, Oct 20, 2015 at 7:45 AM, Etsuro Fujita
wrote:
I found typos in plannodes.h: s/scan.plan.quals/scan.plan.qual/g Please
find attached a patch.
Oops. Good catch. Committed.
Thanks for picking this up!
Best regards,
Etsuro Fujita
--
Sent
On 2015/10/20 13:11, Etsuro Fujita wrote:
On 2015/10/20 5:34, Robert Haas wrote:
On Mon, Oct 19, 2015 at 3:45 AM, Etsuro Fujita
wrote:
As Tom mentioned, just recomputing the original join tuple is not good
enough. We would need to rejoin the test tuples for the baserels
even if
ROW_MARK_COPY
On 2015/10/21 13:34, Kouhei Kaigai wrote:
On 2015/10/20 13:11, Etsuro Fujita wrote:
On 2015/10/20 5:34, Robert Haas wrote:
No. You just need to populate fdw_recheck_quals correctly, same as
for the scan case.
As I said yesterday, that opinion of me is completely wrong. Sorry for
the
of
ROW_MARK_COPY would be an option for the workload where EPQ rechecks are
rarely invoked, because we just need to transfer ctids, not whole-row
images.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
oreign table"?
BTW, I found an incorrect error message in ATWrongRelkindError.
Attached is a patch for fixing the message.
Best regards,
Etsuro Fujita
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index a5bc508..6436d0c 100644
--- a/src/backend/commands/table
On 2015/10/28 6:04, Robert Haas wrote:
On Tue, Oct 20, 2015 at 12:39 PM, Etsuro Fujita
wrote:
Sorry, my explanation was not correct. (Needed to take in caffeine.) What
I'm concerned about is the following:
SELECT * FROM localtab JOIN (ft1 LEFT JOIN ft2 ON ft1.x = ft2.x) ON
localtab.id
On 2015/10/28 20:10, Robert Haas wrote:
On Fri, Oct 23, 2015 at 11:51 AM, Etsuro Fujita
wrote:
BTW, I found an incorrect error message in ATWrongRelkindError. Attached is
a patch for fixing the message.
Committed and back-patched to 9.3.
Thanks!
Best regards,
Etsuro Fujita
--
Sent via
case where those tables use different rowmark
types such as ROW_MARK_COPY and ROW_MARK_EXCLUSIVE, as I pointed out
upthread.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
On 2015/11/04 17:10, Kouhei Kaigai wrote:
On 2015/10/28 6:04, Robert Haas wrote:
On Tue, Oct 20, 2015 at 12:39 PM, Etsuro Fujita
wrote:
Sorry, my explanation was not correct. (Needed to take in caffeine.) What
I'm concerned about is the following:
SELECT * FROM localtab JOIN (ft1 LEFT
ing.
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 2015/11/04 18:50, Etsuro Fujita wrote:
On 2015/11/04 17:10, Kouhei Kaigai wrote:
On 2015/10/28 6:04, Robert Haas wrote:
On Tue, Oct 20, 2015 at 12:39 PM, Etsuro Fujita
wrote:
Sorry, my explanation was not correct. (Needed to take in
caffeine.) What
I'm concerned about is the foll
rming
ExecProcNode, as my patch does [1]. Maybe I'm missing something, though.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/5624d583.10...@lab.ntt.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
re-computed from the whole-row var and
stored in the corresponding estate->es_epqTuple[], the routine wouldn't
allow for what Robert proposed in [2]. To do such a thing, I think we
would probably need to change the existing EPQ machinery more
drastically and rethink the right place for
Hi,
Here is a small patch to update an comment in create_foreignscan_plan;
add fdw_recheck_quals to the list of expressions that need the
replace_nestloop_params processing. I should have updated the comment
when I proposed the patch for the fdw_recheck_quals.
Best regards,
Etsuro Fujita
*** a
On 2015/11/12 2:53, Robert Haas wrote:
On Sun, Nov 8, 2015 at 11:13 PM, Etsuro Fujita
wrote:
To test this change, I think we should update the postgres_fdw patch so as
to add the RecheckForeignScan.
Having said that, as I said previously, I don't see much value in adding the
callback ro
Robert and Kaigai-san,
Sorry, I sent in an unfinished email.
On 2015/11/12 15:30, Kouhei Kaigai wrote:
On 2015/11/12 2:53, Robert Haas wrote:
On Sun, Nov 8, 2015 at 11:13 PM, Etsuro Fujita
wrote:
To test this change, I think we should update the postgres_fdw patch so as
to add the
On 2015/11/10 3:53, Robert Haas wrote:
On Mon, Nov 9, 2015 at 5:34 AM, Etsuro Fujita
wrote:
Here is a small patch to update an comment in create_foreignscan_plan;
add fdw_recheck_quals to the list of expressions that need the
replace_nestloop_params processing. I should have updated the
us email. Sorry for my unfinished email.
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
ronment. I fixed it in a similar fashion of
/src/test/regress/sql/foreign_data.sql. Please find attached a updated
patch for the regression tests.
BTW, What do you think about this?
http://archives.postgresql.org/pgsql-hackers/2012-01/msg00229.php
Best regards,
Etsuro Fujita
*** sql/pgsql_fdw
(2012/02/14 15:15), Shigeru Hanada wrote:
> (2012/02/13 20:50), Etsuro Fujita wrote:
>> The patches have been applied, but role-related regression tests failed
>> in my environment. I fixed it in a similar fashion of
>> /src/test/regress/sql/foreign_data.sql. Please fi
(2012/02/14 19:42), Shigeru Hanada wrote:
> (2012/02/14 17:40), Etsuro Fujita wrote:
>> As discussed at
>> that thread, it would have to change the PlanForeignScan API to let the
>> FDW generate multiple paths and dump
(2012/02/14 23:50), Tom Lane wrote:
> Shigeru Hanada writes:
>> (2012/02/14 17:40), Etsuro Fujita wrote:
>>> As discussed at
>>> that thread, it would have to change the PlanForeignScan API to let the
>>> FDW generate multiple paths and dump them all to add_pat
Hi Hanada-san,
Sorry for the late response.
(2012/02/10 22:05), Shigeru Hanada wrote:
> (2011/12/15 11:30), Etsuro Fujita wrote:
>> (2011/12/14 15:34), Shigeru Hanada wrote:
>>> I think this patch could be marked as "Ready for committer" with some
>>> minor f
(2012/02/15 20:50), Etsuro Fujita wrote:
> (2012/02/14 23:50), Tom Lane wrote:
>>> (2012/02/14 17:40), Etsuro Fujita wrote:
>>>> As discussed at
>>>> that thread, it would have to change the PlanForeignScan API to let the
>>>> FDW generate multipl
users to change the ownership of a foreign server owned by old_role
to new_role that doesn't have USAGE privilege on its foreign data wrapper.
Best regards,
Etsuro Fujita
$ psql postgres
psql (9.2devel)
Type "help" for help.
postgres=# CREATE ROLE reassign_fdw_user LOGIN SUPERUSER;
C
avior, but as far as I know the guiding principle
here is that superusers always can do whatever they please. Maybe what
you point out is a bug in the behavior (both before and after my patch),
but if so, please raise it separately.
OK. Thanks.
Best regards,
Etsuro Fujita
--
Sent via pgsql-ha
(2012/03/05 18:21), Shigeru Hanada wrote:
> (2012/02/21 20:25), Etsuro Fujita wrote:
>> Please find attached an updated version of the patch.
>
> This v2 patch can be applied on HEAD cleanly. Compile completed with
> only one expected warning of scan.c, and all regression tes
(2012/03/05 21:00), Etsuro Fujita wrote:
> (2012/03/05 18:21), Shigeru Hanada wrote:
>> (2012/02/21 20:25), Etsuro Fujita wrote:
>>> Please find attached an updated version of the patch.
>>
>> This v2 patch can be applied on HEAD cleanly. Compile completed with
&
RelOptInfo.fdw_private seems confusing. How about renaming it
to e.g., RelOptInfo.fdw_state?
Attached is a patch for the draft patch.
Best regards,
Etsuro Fujita
*** a/contrib/file_fdw/file_fdw.c
--- b/contrib/file_fdw/file_fdw.c
***
*** 74,87 static const struct FileFdwOption
(2012/03/09 23:48), Tom Lane wrote:
> Etsuro Fujita writes:
Thank you for your answer.
>> 1. FilefdwPlanState.pages and FileFdwPlanState.ntuples seems redundant.
>>Why not use RelOptInfo.pages and RelOptInfo.tuples?
>
> I intentionally avoided setting RelOptInfo.pag
(2012/03/12 13:04), Etsuro Fujita wrote:
> (2012/03/09 23:48), Tom Lane wrote:
>> Etsuro Fujita writes:
>>> 2. IMHO RelOptInfo.fdw_private seems confusing. How about renaming it
>>> to e.g., RelOptInfo.fdw_state?
>>
>> Why is that better? It seems
one should be
present, it may be appropriate to raise an error (just as you
would need to do in the case of a data type mismatch).
Best regards,
Etsuro Fujita
*** a/contrib/file_fdw/file_fdw.c
--- b/contrib/file_fdw/file_fdw.c
***
*** 502,507 fileIterateForeignScan(Foreig
(2012/03/13 15:53), Shigeru HANADA wrote:
> (2012/03/12 19:21), Etsuro Fujita wrote:
>> According to the following documentation on IterateForeignScan() in
>> 50.2. Foreign Data Wrapper Callback Routines, I have created a patch to
>> support the error handling in file_fdw. P
;true', then file_fdw verifies NOT
NULL, CHECK, and foreign key constraints.
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
e, I have to admit that I don't have
any clear idea to make use of the index information stored in the system
catalogs for better query optimization, but I believe that it's useful
for the ORDER BY push down and/or nestloop-with-inner-parametrized-scan
join optimization.
Thoughts?
Best r
(2012/03/16 18:58), Heikki Linnakangas wrote:
> On 16.03.2012 10:44, Etsuro Fujita wrote:
>> I have a plan to support 'Create index on foreign table' for 9.3. Here
>> is my plan.
>>
>> The index creation is supported for a flat file such as CSV and a remote
&
(2012/03/16 22:51), Shigeru Hanada wrote:
2012/3/16 Etsuro Fujita:
The index creation is supported for a flat file such as CSV and a remote
table on a RDB e.g., Postgres using CREATE INDEX.
IMHO CREATE INDEX for foreign tables should have general design,
not specific to some kind of FDWs
(2012/03/17 2:07), David Fetter wrote:
On Fri, Mar 16, 2012 at 11:58:29AM +0200, Heikki Linnakangas wrote:
On 16.03.2012 10:44, Etsuro Fujita wrote:
For a flat file, CREATE INDEX constructs
an index in the same way as an index for a regular table.
For starters, how would you keep the
(2012/03/21 4:39), Robert Haas wrote:
On Fri, Mar 16, 2012 at 4:44 AM, Etsuro Fujita
wrote:
For a flat file, CREATE INDEX constructs an index in the same way as an
index for a regular table.
It seems really weird to have the data half inside the database and
half outside of it like this
be throwaway prototypes), and then looking for a
> common abstraction after he's done a few of those.
OK. I'd like to at first focus on file FDW and Postgres FDW. I'd like
to thank everyone who commented on this topic. Thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers
At 22:11 12/03/28 +0900, Shigeru HANADA wrote:
ANALYZE support for foreign tables is proposed by Fujita-san in current
CF, so I'd like to push it.
I updated the patch to the latest HEAD. Please find attached a patch.
Best regards,
Etsuro Fujita
postgresql-analyze-v7.patch
Descri
Sorry, I sent this email without noticing Hanada-san' earlier email. So,
please look at Hanada-san's post.
Best regards,
Etsuro Fujita
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
Sent: Thurs
Thanks, Hanada-san!
Best regards,
Etsuro Fujita
-Original Message-
From: Shigeru HANADA [mailto:shigeru.han...@gmail.com]
Sent: Friday, April 06, 2012 11:41 AM
To: Etsuro Fujita
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] WIP: Collecting statistics on CSV file data
(2012/04
Thanks!
Best regards,
Etsuro Fujita
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Sent: Saturday, April 07, 2012 4:20 AM
To: Shigeru HANADA
Cc: Etsuro Fujita; pgsql-hackers@postgresql.org
Subject: Re
This is a little patch to fix a typo in contrib/file_fdw.
Best regards,
Etsuro Fujita
file_fdw_typo_fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
> and sets the new flag for consumption far downstream. Why not just make
> > the same check in the planner?
> I've created a patch using this approach.
I've rebased the above patch against the latest head. Could you review the
patch? If you have no objection, I'd
ad. Could you review the
> patch? If you have no objection, I'd like to mark the patch "ready for
> committer".
Sorry, I've had a cleanup of the patch. Please find attached the patch.
Thanks,
Best regards,
Etsuro Fujita
unused-targets-20130618-2.patch
Description
Hi Alexander,
Thank you for the check! I marked the patch "ready for committer".
Best regards,
Etsuro Fujita
From: Alexander Korotkov [mailto:aekorot...@gmail.com]
Sent: Wednesday, June 19, 2013 1:26 AM
To: Etsuro Fujita
Cc: Tom Lane; pgsql-hackers
Subject: Re: [HACKERS]
the removability check in adjust_targetlist() so that the resjunk
column is not used in GROUP BY, DISTINCT ON and *window PARTITION/ORDER BY*,
besides ORDER BY. No? I am open to any comments.
Thanks,
Best regards,
Etsuro Fujita
From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
Sent
> From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
> I guess the patch works fine, but what I'm saying is it might be limited to
> small use cases. Another instance of this that I can think of is ORDER BY
clause
> of window specifications, which you may want to remove from the target list
> as
> From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
> I tried several ways but I couldn't find big problems. Small typo:
> s/rejunk/resjunk/
Thank you for the review. Attached is an updated version of the patch.
Thanks,
Best regards,
Etsuro Fujita
unused-targets-20130621.pat
> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> Etsuro Fujita escribió:
> > > From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
> >
> > > I tried several ways but I couldn't find big problems. Small typo:
> > > s/rejunk/resjunk/
>
gt; my personal bet is that it won't make any difference whatsoever.
To be frank, I agree with Robert.
Sorry for the delay in my review.
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
Attached is a small typo fix patch.
Thanks,
Best regards,
Etsuro Fujita
typofix-20130731.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e of patch anyway. I'd want to rejigger it to be aware of
> the cost implications though, at least for grouping_planner's choices.
+1 for improving KNNGist-style queries.
Sorry for the late response.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pg
st has to make the appropriate Result path and it's done.
> We'd have to create a dummy RelOptInfo representing an empty set of relations,
> which is a bit weird but probably not too unreasonable when all's said and
done.
I think this is reasonable.
Thanks,
Best regards,
Ets
see
http://www.postgresql.org/message-id/14993.1354552...@sss.pgh.pa.us
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
thread? I tried to locate the thread
> based on this description, but couldn't locate it.
Please see
http://www.postgresql.org/message-id/6543.1375470...@sss.pgh.pa.us
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
(if
necessary), and then the t_self will be correctly assigned (0,0) throguh
the whole-row Var in EvalPlanQualFetchRowMarks. So, no inconsistency!
Apart from this, I do not have any comments here.
Thanks again.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-ha
scan.c, it might be better to change
heap_form_tuple to set the t_ctid of a formed tuple to be invalid.
Thanks for the review!
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
patch does? As I mentioned in
[1], ISTM that ExecOpenScanRelation called from ExecInitForeignScan is
assuming that.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/54bcbbf8.3020...@lab.ntt.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 2015/03/13 11:46, Etsuro Fujita wrote:
BTW, what do you think about opening/locking foreign tables selected for
update at InitPlan, which the original patch does? As I mentioned in
[1], ISTM that ExecOpenScanRelation called from ExecInitForeignScan is
assuming that.
[1] http
rrent CF, to scale
up to handling a pushed-down update on a join.
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
at happens
> with those whole-tree stats when some of the children are foreign tables
> that lack ANALYZE support. If the long-term plan is that whole-tree
> stats are going away altogether, then it won't be terribly important
> exactly what happens in that case, so we can just d
On 2015/03/20 21:31, Bruce Momjian wrote:
On Thu, Oct 23, 2014 at 06:29:07PM +0900, Etsuro Fujita wrote:
I don't think that the lock level mentioned in the following comment in
MergeAttributes() in tablecmds.c is right, since that that function has
opened the relation
On 2015/03/21 5:58, Bruce Momjian wrote:
On Thu, Nov 13, 2014 at 08:30:49PM +0900, Etsuro Fujita wrote:
(2014/11/13 20:07), Heikki Linnakangas wrote:
On 11/13/2014 12:45 PM, Etsuro Fujita wrote:
It seems to me there are typos in the reference page for CREATE TABLE.
The structure of the
o do there.
Will work on this issue.
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 2015/03/25 4:56, Tom Lane wrote:
> Etsuro Fujita writes:
>> Let me explain further. Here is the comment in ExecOpenScanRelation:
>
>>* Determine the lock type we need. First, scan to see if target
>> relation
>>* is a result relation. If not,
.
It'd be appreciated if anyone could send back any comments earlier.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/option.c
--- b/contrib/postgres_fdw/option.c
***
*** 105,111 postgres_fdw_validator(PG_FUNCTION_ARGS)
* Validate option value, when we can do so with
On 2015/04/08 7:44, Tom Lane wrote:
> Etsuro Fujita writes:
>> To support ROW_MARK_REFERENCE on (postgres_fdw) foreign tables, I'd like
>> to propose the following FDW APIs:
>
>> RowMarkType
>> GetForeignRowMarkType(Oid relid,
>> L
On 2015/04/10 21:40, Etsuro Fujita wrote:
> On 2015/04/09 12:07, Etsuro Fujita wrote:
>> I'll update the patch, which will contain only an infrastructure for
>> this in the PG core, and will not contain any postgres_fdw change.
>
> I updated the patch based on you
On 2015/04/13 23:25, Jim Nasby wrote:
> On 4/13/15 4:58 AM, Etsuro Fujita wrote:
>> On 2015/04/10 21:40, Etsuro Fujita wrote:
>>> On 2015/04/09 12:07, Etsuro Fujita wrote:
>>>> I'll update the patch, which will contain only an infrastructure for
>>>>
On 2015/03/23 2:57, Tom Lane wrote:
> Etsuro Fujita writes:
>> [ fdw-inh-8.patch ]
>
> I've committed this with some substantial rearrangements, notably:
>
> * I thought that if we were doing this at all, we should go all the way
> and allow foreign tables to be
On 2015/04/15 3:52, Alvaro Herrera wrote:
On 4/14/15 5:49 AM, Etsuro Fujita wrote:
postgres=# create foreign table ft1 (c1 int) server myserver options
(table_name 't1');
CREATE FOREIGN TABLE
postgres=# create foreign table ft2 (c1 int) server myserver options
(table_name 't2&#x
hat
the proposed patch also allows the FDW to change the behavior of FOR NO
KEY UPDATE and/or FOR KEY SHARE row locking so as to match the local
semantics exactly.
BTW, I revised docs a bit. Attached is an updated version of the patch.
Best regards,
Etsuro Fujita
*** a/doc/src/sgml
On 2015/03/23 2:57, Tom Lane wrote:
> Etsuro Fujita writes:
>> [ fdw-inh-8.patch ]
>
> I've committed this with some substantial rearrangements, notably:
> * As I mentioned earlier, I got rid of a few unnecessary restrictions on
> foreign tables so as to avoid introduc
Hi,
Attached is a small patch to mark up on with in
doc/src/sgml/config.sgml.
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index b30c68d..0d8624a 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -6752,7 +6752,7
On 2015/03/05 21:08, Etsuro Fujita wrote:
Here is an updated version.
The EXPLAIN output has also been improved as discussed in [1].
I noticed that the EXPLAIN for a pushed-down update (delete) on
inheritance childs doubly displays "Foreign Update" ("Foreign Delete"),
On 2015/04/16 19:57, Amit Langote wrote:
> On 16-04-2015 PM 07:50, Etsuro Fujita wrote:
>>> The EXPLAIN output has also been improved as discussed in [1].
>>
>> I noticed that the EXPLAIN for a pushed-down update (delete) on inheritance
>> childs doubly displays &qu
t is a good idea because (1) that is contrary to
the reality (the update pushdown patch lets the ForeignScan nodes do
UPDATE/DELETE RETURNING and then do nothing at ModifyTable!) and because
(2) that might cause the problem of associating subplans' update
information with subplans'
On 2015/04/17 13:16, Amit Langote wrote:
> On 17-04-2015 PM 12:35, Etsuro Fujita wrote:
>> (2) that might cause the problem of associating subplans' update
>> information with subplans' scan information, pointed out by Tom [1].
> Having realized how it really
On 2015/04/16 16:05, Etsuro Fujita wrote:
> On 2015/03/23 2:57, Tom Lane wrote:
>> Etsuro Fujita writes:
>>> [ fdw-inh-8.patch ]
>>
>> I've committed this with some substantial rearrangements, notably:
>
>> * As I mentioned earlier, I got rid of
On 2015/04/21 10:07, Kyotaro HORIGUCHI wrote:
At Mon, 20 Apr 2015 16:40:52 +0900, Etsuro Fujita wrote
in <5534ad84.3020...@lab.ntt.co.jp>
However, I'd
like to propose to rename "Foreign Update" ("Foreign Delete") of
ModifyTable simply to "Update" (&
gards,
Etsuro Fujita
*** a/doc/src/sgml/fdwhandler.sgml
--- b/doc/src/sgml/fdwhandler.sgml
***
*** 242,254 IterateForeignScan (ForeignScanState *node);
Note that PostgreSQL's executor doesn't care
! whether the rows returned violate any NOT NULL
! c
would be raised when performing SELECT FOR
UPDATE/SHARE on an inheritance set the parents and childs of which are
all foreign tables, or when performing UPDATE/DELETE involving such an
inheritance set as a source table. Probably, I think your new
RLS-with-inheritance regression tests include such
On 2015/04/22 6:50, Robert Haas wrote:
On Tue, Apr 21, 2015 at 5:45 AM, Etsuro Fujita
wrote:
Since we now allow CHECK constraints to be placed on foreign tables, not
only NOT NULL, I think it'd be better to update docs on considerations
about constraints on foreign tables in fdwhandler
On 2015/04/23 0:34, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
postgres=# select * from ft1 for update;
ERROR: could not find junk tableoid1 column
I think this is a bug. Attached is a patch fixing this issue.
Pushed, thanks!
Thank you.
Best regards
patch for that. I'll add this to the next CF.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/expected/postgres_fdw.out
--- b/contrib/postgres_fdw/expected/postgres_fdw.out
***
*** 3415,3420 CREATE TABLE import_source.t2 (c1 int default 42, c2 varchar NULL, c3 text
Here is a patch to add missing tab-completion for ALTER FOREIGN TABLE.
I'll add this to the next CF.
Best regards,
Etsuro Fujita
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
***
*** 1128,1134 psql_completion(const char *text, int start, in
401 - 500 of 967 matches
Mail list logo
