Daniel Farina dan...@heroku.com writes:
This contains some edits to comments that referred to the obsolete and
bogus TupleDesc scanning. No mechanical alterations.
Applied with some substantial revisions. I didn't like where you'd put
the apply/restore calls, for one thing --- we need to wait
On Fri, Mar 22, 2013 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
This contains some edits to comments that referred to the obsolete and
bogus TupleDesc scanning. No mechanical alterations.
Applied with some substantial revisions. I didn't like
This contains some edits to comments that referred to the obsolete and
bogus TupleDesc scanning. No mechanical alterations.
--- a/contrib/dblink/dblink.c
+++ b/contrib/dblink/dblink.c
@@ -2961,9 +2961,8 @@ initRemoteGucs(remoteGucs *rgs, PGconn *conn)
}
/*
- * Scan a TupleDesc and, should it
On Tue, Mar 19, 2013 at 10:37 PM, Daniel Farina dan...@heroku.com wrote:
I added programming around various NULL returns reading GUCs in this
revision, v4.
Okay, one more of those fridge-logic bugs. Sorry for the noise. v5.
A missing PG_RETHROW to get the properly finally-esque semantics:
Daniel Farina dan...@heroku.com writes:
Okay, one more of those fridge-logic bugs. Sorry for the noise. v5.
A missing PG_RETHROW to get the properly finally-esque semantics:
--- a/contrib/dblink/dblink.c
+++ b/contrib/dblink/dblink.c
@@ -642,7 +642,10 @@ dblink_fetch(PG_FUNCTION_ARGS)
}
On Wed, Mar 20, 2013 at 7:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
Okay, one more of those fridge-logic bugs. Sorry for the noise. v5.
A missing PG_RETHROW to get the properly finally-esque semantics:
--- a/contrib/dblink/dblink.c
+++
Daniel Farina dan...@heroku.com writes:
On Wed, Mar 20, 2013 at 7:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Um ... you shouldn't need a PG_TRY for that at all. guc.c will take
care of popping the values on transaction abort --- that's really rather
the whole point of having that mechanism.
On Thu, Mar 14, 2013 at 8:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
On Tue, Mar 12, 2013 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, watching the remote side's datestyle and intervalstyle and
matching them (for both input and output) would
Daniel Farina dan...@heroku.com writes:
Similar in purpose to cc3f281ffb0a5d9b187e7a7b7de4a045809ff683, but
taking into account that a dblink caller may choose to cause arbitrary
changes to DateStyle and IntervalStyle. To handle this, it is
necessary to use PQparameterStatus before parsing
On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
Similar in purpose to cc3f281ffb0a5d9b187e7a7b7de4a045809ff683, but
taking into account that a dblink caller may choose to cause arbitrary
changes to DateStyle and IntervalStyle. To
Daniel Farina dan...@heroku.com writes:
On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be inclined to eat the cost of calling PQparameterStatus every time
(which won't be that much) and instead try to optimize by avoiding the
GUC-setting overhead if the current value
On Tue, Mar 19, 2013 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be inclined to eat the cost of calling PQparameterStatus every time
(which won't be that much) and instead try to
On Tue, Mar 19, 2013 at 3:06 PM, Daniel Farina dan...@heroku.com wrote:
On Tue, Mar 19, 2013 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be inclined to eat the cost of calling
On Tue, Mar 19, 2013 at 6:10 PM, Daniel Farina dan...@heroku.com wrote:
On Tue, Mar 19, 2013 at 3:06 PM, Daniel Farina dan...@heroku.com wrote:
On Tue, Mar 19, 2013 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 11, 2013 at 3:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
It feels a bit like unpredictable magic to have DEFAULT mean one
thing and omitted columns mean something else.
Agreed. The current code behaves
On Tue, Mar 12, 2013 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
Okay, I see. So inverting the thinking I wrote earlier: how about
hearkening carefully to any ParameterStatus messages on the local side
before entering the inner loop of
Daniel Farina dan...@heroku.com writes:
On Tue, Mar 12, 2013 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, watching the remote side's datestyle and intervalstyle and
matching them (for both input and output) would probably work.
Alright, so I've been whacking at this and there's one
On Mon, Mar 11, 2013 at 3:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
It feels a bit like unpredictable magic to have DEFAULT mean one
thing and omitted columns mean something else.
Agreed. The current code behaves that way, but I think that's
indisputably a
Tom Lane wrote:
Yeah, I'm drifting towards the position that we should just define the
defaults as being whatever they are locally, rather than trying to be
cute about supporting remotely-executed defaults. It looks to me like
if we try to do the latter, we're going to have pitfalls and weird
Albe Laurenz laurenz.a...@wien.gv.at writes:
Yeah, I'm drifting towards the position that we should just define the
defaults as being whatever they are locally, rather than trying to be
cute about supporting remotely-executed defaults.
That was my first thought on the topic, to have a
On 13 March 2013 19:04, Tom Lane t...@sss.pgh.pa.us wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
Yeah, I'm drifting towards the position that we should just define the
defaults as being whatever they are locally, rather than trying to be
cute about supporting remotely-executed defaults.
Thom Brown t...@linux.com writes:
How about:
CREATE FOREIGN TABLE tablename (id int DEFAULT PASSTHROUGH) SERVER pg_server;
That way it will pass DEFAULT through to the remote table as it's
defined on the table. Users can then explicitly insert values, or
select the default, which will
Tom Lane wrote:
Thom Brown t...@linux.com writes:
Out of curiosity, is there any way to explicitly force a foreign
DEFAULT with column-omission?
I've concluded that the ideal behavior probably is that if you have
declared a DEFAULT expression for a foreign table's column, then that's
what
On Mon, Mar 11, 2013 at 7:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
I will try to make time for this, although it seems like the general
approach should match pgsql_fdw if possible. Is the current thinking
to forward the settings and then use the GUC
Daniel Farina dan...@heroku.com writes:
Okay, I see. So inverting the thinking I wrote earlier: how about
hearkening carefully to any ParameterStatus messages on the local side
before entering the inner loop of dblink.c:materializeResult as to set
the local GUC (and carefully dropping it back
Albe Laurenz laurenz.a...@wien.gv.at writes:
Do you think that it is possible to insert remote defaults
by omitting columns like this:
INSERT INTO foreigntable (col1, col3) VALUES (a, c);
Well, that's how it works right now, but it's not good that it's
inconsistent with the explicit-DEFAULT
Daniel Farina dan...@heroku.com writes:
On Sun, Mar 10, 2013 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm ... the buildfarm just rubbed my nose in a more immediate issue,
which is that postgres_fdw is vulnerable to problems if the remote
server is using different GUC settings than it is
The remote end has entirely misinterpreted the day vs month fields.
Now, to hit this you need to be using a datestyle which will print
in an ambiguous format, so the ISO and Postgres styles are
not vulnerable; but German and SQL are.
Is the timezone GUC a problem, also, for this? Seems like
Josh Berkus j...@agliodbs.com writes:
The remote end has entirely misinterpreted the day vs month fields.
Now, to hit this you need to be using a datestyle which will print
in an ambiguous format, so the ISO and Postgres styles are
not vulnerable; but German and SQL are.
Is the timezone GUC
Having said that, I'd still be inclined to try to set the remote's
timezone GUC just so that error messages coming back from the remote
don't reflect a randomly different timezone, which was the basic issue
in the buildfarm failures we saw yesterday. OTOH, there is no guarantee
at all that
I wrote:
Thom Brown t...@linux.com writes:
Out of curiosity, is there any way to explicitly force a foreign
DEFAULT with column-omission?
That's one of the things that would have to be worked out before
we could implement anything here. The easy answer would be that DEFAULT
specifies the
On Sun, Mar 10, 2013 at 10:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another thing that would be easy to implement is to say that the new row
value is fully determined locally (including defaults if any) and remote
defaults have nothing to do with it. But I think that's almost
certainly a
Greg Stark st...@mit.edu writes:
It feels a bit like unpredictable magic to have DEFAULT mean one
thing and omitted columns mean something else.
Agreed. The current code behaves that way, but I think that's
indisputably a bug not behavior we want to keep.
Perhaps we should have
an explicit
On 11 March 2013 19:00, Greg Stark st...@mit.edu wrote:
On Sun, Mar 10, 2013 at 10:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another thing that would be easy to implement is to say that the new row
value is fully determined locally (including defaults if any) and remote
defaults have nothing
Josh Berkus j...@agliodbs.com writes:
Having said that, I'd still be inclined to try to set the remote's
timezone GUC just so that error messages coming back from the remote
don't reflect a randomly different timezone, which was the basic issue
in the buildfarm failures we saw yesterday.
On Mon, Mar 11, 2013 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, it strikes me that dblink is probably subject to at least some of
these same failure modes. I'm not personally volunteering to fix any
of this in dblink, but maybe someone ought to look into that.
I will try to make
Daniel Farina dan...@heroku.com writes:
I will try to make time for this, although it seems like the general
approach should match pgsql_fdw if possible. Is the current thinking
to forward the settings and then use the GUC hooks to track updates?
That's not what I had in mind for postgres_fdw
Kohei KaiGai kai...@kaigai.gr.jp writes:
[ pgsql-v9.3-writable-fdw-poc.v12.part-1/2.patch ]
Applied after rather extensive editorialization. DELETE RETURNING in
particular was a mess, and I also tried to make SELECT FOR UPDATE behave
in what seemed like a sane fashion.
There's a lot left to do
I wrote:
There's a lot left to do here of course. One thing I was wondering
about was why we don't allow DEFAULTs to be attached to foreign-table
columns. There was no use in it before, but it seems sensible enough
now.
Hmm ... the buildfarm just rubbed my nose in a more immediate issue,
On 03/10/2013 02:32 PM, Tom Lane wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
[ pgsql-v9.3-writable-fdw-poc.v12.part-1/2.patch ]
Applied after rather extensive editorialization. DELETE RETURNING in
particular was a mess, and I also tried to make SELECT FOR UPDATE behave
in what seemed
On 10 March 2013 18:32, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
[ pgsql-v9.3-writable-fdw-poc.v12.part-1/2.patch ]
Applied after rather extensive editorialization. DELETE RETURNING in
particular was a mess, and I also tried to make SELECT FOR UPDATE behave
On 10 March 2013 20:38, Thom Brown t...@linux.com wrote:
On 10 March 2013 18:32, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
[ pgsql-v9.3-writable-fdw-poc.v12.part-1/2.patch ]
Applied after rather extensive editorialization. DELETE RETURNING in
particular was
Andrew Dunstan and...@dunslane.net writes:
Excellent news. But I noticed as I went to update my non-writeable FDW
that this has happened in the regression tests. Is this correct?
Yeah, see the adjustment I made in the file_fdw test (which that looks
to be borrowed from).
The new theory is
Thom Brown t...@linux.com writes:
On 10 March 2013 18:32, Tom Lane t...@sss.pgh.pa.us wrote:
There's a lot left to do here of course. One thing I was wondering
about was why we don't allow DEFAULTs to be attached to foreign-table
columns. There was no use in it before, but it seems sensible
On Sun, Mar 10, 2013 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
There's a lot left to do here of course. One thing I was wondering
about was why we don't allow DEFAULTs to be attached to foreign-table
columns. There was no use in it before, but it seems sensible enough
now.
2013/3/3 Tom Lane t...@sss.pgh.pa.us:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/08/2013 01:03 AM, Kohei KaiGai wrote:
The attached patch adds Daniel's reworks on make_modifytable
invocation, and add a short comment on add_base_rels_to_query(). Rest
of portion has not been changed from
On 02/08/2013 01:03 AM, Kohei KaiGai wrote:
The attached patch adds Daniel's reworks on make_modifytable
invocation, and add a short comment on add_base_rels_to_query(). Rest
of portion has not been changed from the previous version.
How's this looking for 9.3? On-list discussion seems to have
Craig Ringer cr...@2ndquadrant.com writes:
On 02/08/2013 01:03 AM, Kohei KaiGai wrote:
The attached patch adds Daniel's reworks on make_modifytable
invocation, and add a short comment on add_base_rels_to_query(). Rest
of portion has not been changed from the previous version.
How's this
On 03/03/2013 11:17 PM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/08/2013 01:03 AM, Kohei KaiGai wrote:
The attached patch adds Daniel's reworks on make_modifytable
invocation, and add a short comment on add_base_rels_to_query(). Rest
of portion has not been changed
On Fri, Feb 1, 2013 at 2:22 AM, Daniel Farina dan...@heroku.com wrote:
On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I noticed the v10 patch cannot be applied on the latest master branch
cleanly. The attached ones were rebased.
Anyway, I'm looking at the first
On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I noticed the v10 patch cannot be applied on the latest master branch
cleanly. The attached ones were rebased.
Hello,
I'm just getting started looking at this, but notice that the second
patch relies on
2013/2/1 Daniel Farina dan...@heroku.com:
On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I noticed the v10 patch cannot be applied on the latest master branch
cleanly. The attached ones were rebased.
Hello,
I'm just getting started looking at this, but notice that
Hello.
I've tried to implement this API for our Multicorn FDW, and I have a few
questions about the API.
First, I don't understand what are the requirements on the rowid
pseudo-column values.
In particular, this sentence from a previous mail makes it ambiguous to me:
At the beginning, I
Hi,
2012/12/18 Ronan Dunklau rdunk...@gmail.com:
Hello.
I've tried to implement this API for our Multicorn FDW, and I have a few
questions about the API.
First, I don't understand what are the requirements on the rowid
pseudo-column values.
In particular, this sentence from a previous
On Wed, December 12, 2012 14:45, Kohei KaiGai wrote:
pgsql-v9.3-writable-fdw-poc.v8.part-2.patch 151 k
pgsql-v9.3-writable-fdw-poc.v8.part-1.patch 70 k
I wanted to have a look at this, and tried to apply part 1, en then part 2 on
top of that (that's
the idea, right?)
part 1 applies and
Erik Rijkers wrote:
pgsql-v9.3-writable-fdw-poc.v8.part-2.patch 151 k
pgsql-v9.3-writable-fdw-poc.v8.part-1.patch 70 k
I wanted to have a look at this, and tried to apply part 1, en then part 2 on
top of that (that's
the idea, right?)
part 1 applies and then part 2 does not.
Part 2
Kohei KaiGai wrote:
The attached patch is revised version.
One most difference from the previous version is, it constructed
PoC features on Hanada-san's latest postgres-fdw.v5.patch.
Yesh, it looks to me working fine on RDBMS backend also.
Cool.
Even though the filename of this patch
Kohei KaiGai wrote:
This design tries to kill two-birds with one-stone.
It enables to add multiple number of pseudo-columns,
not only rowid, and makes possible to push-down
complex calculation of target list into external computing
resource.
For example, when user gives the following query:
2012/11/20 Albe Laurenz laurenz.a...@wien.gv.at:
Kohei KaiGai wrote:
This design tries to kill two-birds with one-stone.
It enables to add multiple number of pseudo-columns,
not only rowid, and makes possible to push-down
complex calculation of target list into external computing
resource.
Kohei KaiGai wrote:
Probably, it is helpful to provide a helper function that fetches an
attribute-
number of pseudo rowid column from the supplied targetlist.
If we have GetPseudoRowidColumn() at foreign/foreign.c, the avove
routine can be rewritten as:
static AttrNumber
Kohei KaiGai wrote:
I am not so happy with GetForeignRelInfo:
- The name seems ill-chosen from the FDW API side.
I guess that you chose the name because the function
is called from get_relation_info, but I think the name
should be more descriptive for the FDW API.
Something like
2012/11/19 Albe Laurenz laurenz.a...@wien.gv.at:
Kohei KaiGai wrote:
I am not so happy with GetForeignRelInfo:
- The name seems ill-chosen from the FDW API side.
I guess that you chose the name because the function
is called from get_relation_info, but I think the name
should be more
Kohei KaiGai wrote:
The attached patch is just a refreshed version for clean applying to
the latest tree.
As previous version doing, it makes pseudo enhancement on file_fdw
to print something about the supplied tuple on INSERT, UPDATE and
DELETE statement.
Basics:
---
The patch
Awesome.
I would love to implement this API in JDBC_FDW.
Atri
Sent from my iPad
On 16-Nov-2012, at 20:20, Albe Laurenz laurenz.a...@wien.gv.at wrote:
Kohei KaiGai wrote:
The attached patch is just a refreshed version for clean applying to
the latest tree.
As previous version doing, it
2012/11/16 Albe Laurenz laurenz.a...@wien.gv.at:
Kohei KaiGai wrote:
The attached patch is just a refreshed version for clean applying to
the latest tree.
As previous version doing, it makes pseudo enhancement on file_fdw
to print something about the supplied tuple on INSERT, UPDATE and
Alexander Korotkov wrote:
2) You wrote that FDW can support or don't support write depending on
having corresponding functions.
However it's likely some tables of same FDW could be writable while
another are not. I think we should
have some mechanism for FDW telling whether particular table is
On 08-Nov-2012, at 13:35, Albe Laurenz laurenz.a...@wien.gv.at wrote:
Alexander Korotkov wrote:
2) You wrote that FDW can support or don't support write depending on
having corresponding functions.
However it's likely some tables of same FDW could be writable while
another are not. I think
2012/11/2 Alexander Korotkov aekorot...@gmail.com:
On Mon, Sep 24, 2012 at 12:49 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/9/23 Kohei KaiGai kai...@kaigai.gr.jp:
2012/8/29 Kohei KaiGai kai...@kaigai.gr.jp:
2012/8/28 Kohei KaiGai kai...@kaigai.gr.jp:
2012/8/28 Tom Lane
On Mon, Sep 24, 2012 at 12:49 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/9/23 Kohei KaiGai kai...@kaigai.gr.jp:
2012/8/29 Kohei KaiGai kai...@kaigai.gr.jp:
2012/8/28 Kohei KaiGai kai...@kaigai.gr.jp:
2012/8/28 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp writes:
Tom Lane wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
Laurenz Albe wrote:
Would it be too invasive to introduce a new pointer in
TupleTableSlot
that is NULL for anything but virtual tuples from foreign tables?
I'm not certain whether the duration of TupleTableSlot is enough to
carry a
2012/9/13 Albe Laurenz laurenz.a...@wien.gv.at:
Tom Lane wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
Laurenz Albe wrote:
Would it be too invasive to introduce a new pointer in
TupleTableSlot
that is NULL for anything but virtual tuples from foreign tables?
I'm not certain whether the
Albe Laurenz laurenz.a...@wien.gv.at writes:
Tom Lane wrote:
Instead, the planner arranges for the TID to be carried up as an
explicit resjunk column named ctid. (Currently this is done in
rewriteTargetListUD(), but see also preptlist.c which does some
related things for SELECT FOR UPDATE.)
2012/8/28 Kohei KaiGai kai...@kaigai.gr.jp:
2012/8/28 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp writes:
Would it be too invasive to introduce a new pointer in TupleTableSlot
that is NULL for anything but virtual tuples from foreign tables?
I'm not certain whether the
2012/8/28 David Fetter da...@fetter.org:
On Tue, Aug 28, 2012 at 06:08:59PM +0200, Kohei KaiGai wrote:
2012/8/28 David Fetter da...@fetter.org:
On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
2012/8/28 David Fetter da...@fetter.org:
On Tue, Aug 28, 2012 at 10:58:25AM -0400,
2012/8/27 Albe Laurenz laurenz.a...@wien.gv.at:
Kohei KaiGai wrote:
2012/8/25 Robert Haas robertmh...@gmail.com:
On Thu, Aug 23, 2012 at 1:10 AM, Kohei KaiGai kai...@kaigai.gr.jp
wrote:
It is a responsibility of FDW extension (and DBA) to ensure each
foreign-row has a unique identifier that
2012/8/27 Shigeru HANADA shigeru.han...@gmail.com:
Kaigai-san,
On Thu, Aug 23, 2012 at 2:10 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The patched portion at contrib/file_fdw.c does not make sense
actually. It just prints messages for each invocation.
It is just a proof-of-concept to show
Kohei KaiGai wrote:
It is a responsibility of FDW extension (and DBA) to ensure each
foreign-row has a unique identifier that has 48-bits width integer
data type in maximum.
For example, if primary key of the remote table is Text data type,
an idea is to use a hash table to track the
2012/8/28 Albe Laurenz laurenz.a...@wien.gv.at:
Kohei KaiGai wrote:
It is a responsibility of FDW extension (and DBA) to ensure each
foreign-row has a unique identifier that has 48-bits width integer
data type in maximum.
For example, if primary key of the remote table is Text data type,
an
Kohei KaiGai kai...@kaigai.gr.jp writes:
Would it be too invasive to introduce a new pointer in TupleTableSlot
that is NULL for anything but virtual tuples from foreign tables?
I'm not certain whether the duration of TupleTableSlot is enough to
carry a private datum between scan and modify
Kohei KaiGai kai...@kaigai.gr.jp writes:
It seems to me TargetEntry of the parse tree can inform us which column
should be modified on UPDATE or INSERT. If it has just a Var element
that reference original table as-is, it means here is no change.
Only if you're not going to support BEFORE
On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
It seems to me TargetEntry of the parse tree can inform us which column
should be modified on UPDATE or INSERT. If it has just a Var element
that reference original table as-is, it means here
2012/8/28 David Fetter da...@fetter.org:
On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
It seems to me TargetEntry of the parse tree can inform us which column
should be modified on UPDATE or INSERT. If it has just a Var element
that
On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
2012/8/28 David Fetter da...@fetter.org:
On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
It seems to me TargetEntry of the parse tree can inform us
which column should be
2012/8/28 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp writes:
Would it be too invasive to introduce a new pointer in TupleTableSlot
that is NULL for anything but virtual tuples from foreign tables?
I'm not certain whether the duration of TupleTableSlot is enough to
carry a
2012/8/28 David Fetter da...@fetter.org:
On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
2012/8/28 David Fetter da...@fetter.org:
On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
It seems to me TargetEntry of the parse tree
On Tue, Aug 28, 2012 at 06:08:59PM +0200, Kohei KaiGai wrote:
2012/8/28 David Fetter da...@fetter.org:
On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
2012/8/28 David Fetter da...@fetter.org:
On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
Kohei KaiGai
Kohei KaiGai wrote:
2012/8/25 Robert Haas robertmh...@gmail.com:
On Thu, Aug 23, 2012 at 1:10 AM, Kohei KaiGai kai...@kaigai.gr.jp
wrote:
It is a responsibility of FDW extension (and DBA) to ensure each
foreign-row has a unique identifier that has 48-bits width integer
data type in maximum.
Kaigai-san,
On Thu, Aug 23, 2012 at 2:10 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The patched portion at contrib/file_fdw.c does not make sense
actually. It just prints messages for each invocation.
It is just a proof-of-concept to show possibility of implementation
based on real RDBMS.
On Thu, Aug 23, 2012 at 1:10 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is a responsibility of FDW extension (and DBA) to ensure each
foreign-row has a unique identifier that has 48-bits width integer
data type in maximum.
It strikes me as incredibly short-sighted to decide that the row
2012/8/25 Robert Haas robertmh...@gmail.com:
On Thu, Aug 23, 2012 at 1:10 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is a responsibility of FDW extension (and DBA) to ensure each
foreign-row has a unique identifier that has 48-bits width integer
data type in maximum.
It strikes me as
Hello,
The attached patch is just a proof-of-concept of writable foreign table
feature; thus, I don't expect it getting merged at the upcoming commit
fest. The purpose of this patch is to find out the best way to support
write stuff in FDW.
Basic idea of this patch is to utilize ctid field to
91 matches
Mail list logo
