Hi,
On Fri, 3 Feb 2017 18:12:01 +0900
vinayak wrote:
> Hello,
>
> I have tested some scenarios of inserting data into two foreign tables
> using postgres_fdw. All the test cases works fine except Test 5.
>
> In Test 5, I am expecting error as both the rows violates the
> constraint. But at t
Hello,
I have tested some scenarios of inserting data into two foreign tables
using postgres_fdw. All the test cases works fine except Test 5.
In Test 5, I am expecting error as both the rows violates the
constraint. But at the COMMIT time transaction does not give any error
and it takes loc
(2014/11/23 6:16), Tom Lane wrote:
> I committed this with some cosmetic adjustments, and one not-so-cosmetic
> one:
Thanks for improving and committing the patch!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On Sun, Nov 23, 2014 at 2:46 AM, Tom Lane wrote:
> Etsuro Fujita writes:
> > (2014/11/19 18:21), Ashutosh Bapat wrote:
> >> Ok. I added that comment to the commitfest and changed the status to
> >> "ready for commiter".
>
> > Many thanks!
>
> I committed this with some cosmetic adjustments, and
Etsuro Fujita writes:
> (2014/11/19 18:21), Ashutosh Bapat wrote:
>> Ok. I added that comment to the commitfest and changed the status to
>> "ready for commiter".
> Many thanks!
I committed this with some cosmetic adjustments, and one not-so-cosmetic
one: I left it continuing to allow CTID condi
(2014/11/19 18:21), Ashutosh Bapat wrote:
Ok. I added that comment to the commitfest and changed the status to
"ready for commiter".
Many thanks!
PS: the link to the review emails that discuss the issue doesn't work
properly, so I re-added the link.
Best regards,
Etsuro Fujita
--
Sent via
Ok. I added that comment to the commitfest and changed the status to "ready
for commiter".
On Wed, Nov 19, 2014 at 1:10 PM, Etsuro Fujita
wrote:
> (2014/11/19 15:56), Ashutosh Bapat wrote:
>
>> On Wed, Nov 19, 2014 at 12:14 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
(2014/11/19 15:56), Ashutosh Bapat wrote:
On Wed, Nov 19, 2014 at 12:14 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/19 14:58), Ashutosh Bapat wrote:
May be we should modify use_physical_tlist() to return
false in
case of RELKIND_FOREIGN_TA
(2014/11/19 14:55), Etsuro Fujita wrote:
(2014/11/18 18:37), Ashutosh Bapat wrote:
On Tue, Nov 18, 2014 at 1:55 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/17 19:54), Ashutosh Bapat wrote:
Here are comments for postgres_fdw-syscol patch.
3. Si
On Wed, Nov 19, 2014 at 12:14 PM, Etsuro Fujita wrote:
> (2014/11/19 14:58), Ashutosh Bapat wrote:
>
>> On Wed, Nov 19, 2014 at 11:18 AM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>> (2014/11/18 18:27), Ashutosh Bapat wrote:
>> On Tue, Nov 18, 2014 at 1:50 PM, Etsur
(2014/11/19 14:58), Ashutosh Bapat wrote:
On Wed, Nov 19, 2014 at 11:18 AM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/18 18:27), Ashutosh Bapat wrote:
On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita
Here are my comments about the pat
On Wed, Nov 19, 2014 at 11:18 AM, Etsuro Fujita wrote:
> (2014/11/18 18:27), Ashutosh Bapat wrote:
>
>> On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>> (2014/11/17 19:36), Ashutosh Bapat wrote:
>>
>
> Here are my comments about the pat
(2014/11/18 18:37), Ashutosh Bapat wrote:
On Tue, Nov 18, 2014 at 1:55 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/17 19:54), Ashutosh Bapat wrote:
Here are comments for postgres_fdw-syscol patch.
Code
---
1. Instead of a si
(2014/11/18 18:27), Ashutosh Bapat wrote:
On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/17 19:36), Ashutosh Bapat wrote:
Here are my comments about the patch fscan_reltargetlist.patch
2. Instead of using rel->reltarge
On Tue, Nov 18, 2014 at 1:55 PM, Etsuro Fujita
wrote:
> (2014/11/17 19:54), Ashutosh Bapat wrote:
>
>> Here are comments for postgres_fdw-syscol patch.
>>
>
> Thanks for the review!
>
> Code
>> ---
>> 1. Instead of a single liner comment "System columns can't be sent to
>> remote.", it might
On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita
wrote:
> (2014/11/17 19:36), Ashutosh Bapat wrote:
>
>> Here are my comments about the patch fscan_reltargetlist.patch
>>
>
> Thanks for the review!
>
> 1. This isn't your change, but we might be able to get rid of assignment
>> 2071 /* Are any
(2014/11/17 19:54), Ashutosh Bapat wrote:
Here are comments for postgres_fdw-syscol patch.
Thanks for the review!
Code
---
1. Instead of a single liner comment "System columns can't be sent to
remote.", it might be better to explain why system columns can't be sent
to the remote.
Done.
(2014/11/17 19:36), Ashutosh Bapat wrote:
Here are my comments about the patch fscan_reltargetlist.patch
Thanks for the review!
1. This isn't your change, but we might be able to get rid of assignment
2071 /* Are any system columns requested from rel? */
2072 scan_plan->fsSystemCol =
Hi Fujita-san,
Here are comments for postgres_fdw-syscol patch.
Sanity
The patch applies and compiles cleanly.
The server regression and regression in contrib/postgres_fdw,file_fdw run
cleanly.
Code
---
1. Instead of a single liner comment "System columns can't be sent to
remote.",
Hi Fujita-san,
Here are my comments about the patch fscan_reltargetlist.patch
Sanity
Patch applies and compiles cleanly.
Regressions in test/regress folder and postgres_fdw and file_fdw are clean.
1. This isn't your change, but we might be able to get rid of assignment
2071 /* Are an
(2014/11/11 18:45), Etsuro Fujita wrote:
(2014/11/10 20:05), Ashutosh Bapat wrote:
Since two separate issues 1. using reltargetlist instead of attr_needed
and 2. system columns usage in FDW are being tackled here, we should
separate the patch into two one for each of the issues.
Agreed. Will
Hi Ashutosh,
Thanks for the review!
(2014/11/10 20:05), Ashutosh Bapat wrote:
Since two separate issues 1. using reltargetlist instead of attr_needed
and 2. system columns usage in FDW are being tackled here, we should
separate the patch into two one for each of the issues.
Agreed. Will spli
Since two separate issues 1. using reltargetlist instead of attr_needed and
2. system columns usage in FDW are being tackled here, we should separate
the patch into two one for each of the issues.
While I agree that the system columns shouldn't be sent to the remote node,
it doesn't look clear to
(2014/10/14 8:53), Robert Haas wrote:
On Mon, Oct 13, 2014 at 3:30 PM, Bruce Momjian wrote:
Uh, where are we on this patch?
Probably it should be added to the upcoming CF.
Done.
https://commitfest.postgresql.org/action/patch_view?id=1599
Thanks,
Best regards,
Etsuro Fujita
--
Sent via
On Mon, Oct 13, 2014 at 3:30 PM, Bruce Momjian wrote:
> Uh, where are we on this patch?
Probably it should be added to the upcoming CF.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
Uh, where are we on this patch?
---
On Mon, Sep 8, 2014 at 09:30:32PM +0900, Etsuro Fujita wrote:
> (2014/09/02 18:55), Etsuro Fujita wrote:
> > (2014/09/01 20:15), Etsuro Fujita wrote:
> >> While working on [1], I've found
(2014/09/02 18:55), Etsuro Fujita wrote:
> (2014/09/01 20:15), Etsuro Fujita wrote:
>> While working on [1], I've found that postgres_fdw behaves oddly:
I've revised the patch a bit further. Please find attached a patch.
Thanks,
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
-
(2014/09/01 20:15), Etsuro Fujita wrote:
> While working on [1], I've found that postgres_fdw behaves oddly:
>
> postgres=# create foreign table ft (a int) server loopback options
> (table_name 't');
> CREATE FOREIGN TABLE
> postgres=# select tableoid, * from ft;
> tableoid | a
> --+---
While working on [1], I've found that postgres_fdw behaves oddly:
postgres=# create foreign table ft (a int) server loopback options
(table_name 't');
CREATE FOREIGN TABLE
postgres=# select tableoid, * from ft;
tableoid | a
--+---
16400 | 1
(1 row)
postgres=# select tableoid, * from
29 matches
Mail list logo
