On Fri, Mar 22, 2013 at 12:29 PM, Tom Lane wrote:
> Daniel Farina 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/rest
Daniel Farina 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 to do the
appli
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 c
Daniel Farina writes:
> On Wed, Mar 20, 2013 at 7:43 AM, Tom Lane 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.
> Hmm, well, merely raising th
On Wed, Mar 20, 2013 at 7:43 AM, Tom Lane wrote:
> Daniel Farina 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
Daniel Farina 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)
> }
> PG_CATC
On Tue, Mar 19, 2013 at 10:37 PM, Daniel Farina 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:
--- a/contrib/dbli
On Tue, Mar 19, 2013 at 6:10 PM, Daniel Farina wrote:
> On Tue, Mar 19, 2013 at 3:06 PM, Daniel Farina wrote:
>> On Tue, Mar 19, 2013 at 2:41 PM, Tom Lane wrote:
>>> Daniel Farina writes:
On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane wrote:
> I'd be inclined to eat the cost of calling PQp
On Tue, Mar 19, 2013 at 3:06 PM, Daniel Farina wrote:
> On Tue, Mar 19, 2013 at 2:41 PM, Tom Lane wrote:
>> Daniel Farina writes:
>>> On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane wrote:
I'd be inclined to eat the cost of calling PQparameterStatus every time
(which won't be that much) and
On Tue, Mar 19, 2013 at 2:41 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane 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 over
Daniel Farina writes:
> On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane 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 matches the local setting.
>>
On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane wrote:
> Daniel Farina 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
Daniel Farina 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 any input, every
On Thu, Mar 14, 2013 at 8:07 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Tue, Mar 12, 2013 at 11:51 AM, Tom Lane 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 whackin
Robert Haas writes:
> On Mon, Mar 11, 2013 at 3:06 PM, Tom Lane wrote:
>> Greg Stark 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
>> indisputabl
On Mon, Mar 11, 2013 at 3:06 PM, Tom Lane wrote:
> Greg Stark 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 wan
Daniel Farina writes:
> On Tue, Mar 12, 2013 at 11:51 AM, Tom Lane 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 interesting
> thing to ask abou
On Tue, Mar 12, 2013 at 11:51 AM, Tom Lane wrote:
> Daniel Farina 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
>> th
Thom Brown 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 configured to
On 13 March 2013 19:04, Tom Lane wrote:
> Albe Laurenz 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
Albe Laurenz 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 solution that
> is simpl
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 we
Albe Laurenz 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 case.
> If that can be
Daniel Farina 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 off after
> m
On Mon, Mar 11, 2013 at 7:04 PM, Tom Lane wrote:
> Daniel Farina 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?
>
> Tha
Tom Lane wrote:
>> Thom Brown 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 the
Daniel Farina 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 --- rather the
On Mon, Mar 11, 2013 at 12:30 PM, Tom Lane 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 time for this, alth
Josh Berkus 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. OTOH, there is
On 11 March 2013 19:00, Greg Stark wrote:
> On Sun, Mar 10, 2013 at 10:01 PM, Tom Lane 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 thin
Greg Stark 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 LOCAL DE
On Sun, Mar 10, 2013 at 10:01 PM, Tom Lane 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 usability fail ---
I wrote:
> Thom Brown 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 local de
> 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 t
Josh Berkus 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
> 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
Daniel Farina writes:
> On Sun, Mar 10, 2013 at 12:15 PM, Tom Lane 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 for things like
>> timezone
On Sun, Mar 10, 2013 at 12:15 PM, Tom Lane 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.
>
> Hmm ...
Thom Brown writes:
> On 10 March 2013 18:32, Tom Lane 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.
> postgres
Andrew Dunstan 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 that SELECT FOR UPDAT
On 10 March 2013 20:38, Thom Brown wrote:
> On 10 March 2013 18:32, Tom Lane wrote:
>> Kohei KaiGai 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
On 10 March 2013 18:32, Tom Lane wrote:
> Kohei KaiGai 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 fa
On 03/10/2013 02:32 PM, Tom Lane wrote:
Kohei KaiGai 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.
T
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,
Kohei KaiGai 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 here of course. O
2013/3/3 Tom Lane :
> Craig Ringer 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.
>
>> H
On 03/03/2013 11:17 PM, Tom Lane wrote:
> Craig Ringer 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 prev
Craig Ringer 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 looking for 9.3? O
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 hav
On Fri, Feb 1, 2013 at 2:22 AM, Daniel Farina wrote:
> On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai 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 patch, which applies neatly. Thanks
2013/2/1 Daniel Farina :
> On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai 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
On Tue, Jan 29, 2013 at 1:19 AM, Kohei KaiGai 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 contrib/postgres_fdw to apply, but i
Hi,
2012/12/18 Ronan Dunklau :
> 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
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 con
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.
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 t
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:
> 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
> fileGetFo
2012/11/20 Albe Laurenz :
> 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:
>>> 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 give
2012/11/19 Albe Laurenz :
> 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 descripti
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.
>> Somethin
2012/11/16 Albe Laurenz :
> 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 stateme
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" wrote:
> 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 e
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 a
On 08-Nov-2012, at 13:35, "Albe Laurenz" 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 we should
>> h
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 i
2012/11/2 Alexander Korotkov :
> On Mon, Sep 24, 2012 at 12:49 PM, Kohei KaiGai wrote:
>>
>> 2012/9/23 Kohei KaiGai :
>> > 2012/8/29 Kohei KaiGai :
>> >> 2012/8/28 Kohei KaiGai :
>> >>> 2012/8/28 Tom Lane :
>> Kohei KaiGai writes:
>> >> Would it be too invasive to introduce a new pointer
On Mon, Sep 24, 2012 at 12:49 PM, Kohei KaiGai wrote:
> 2012/9/23 Kohei KaiGai :
> > 2012/8/29 Kohei KaiGai :
> >> 2012/8/28 Kohei KaiGai :
> >>> 2012/8/28 Tom Lane :
> Kohei KaiGai writes:
> >> Would it be too invasive to introduce a new pointer in
> TupleTableSlot
> >> that is NUL
"Albe Laurenz" 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.)
>>
>> I'm in
2012/9/13 Albe Laurenz :
> Tom Lane wrote:
>> Kohei KaiGai 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 TupleTableSlo
Tom Lane wrote:
> Kohei KaiGai 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 private d
2012/8/28 David Fetter :
> On Tue, Aug 28, 2012 at 06:08:59PM +0200, Kohei KaiGai wrote:
>> 2012/8/28 David Fetter :
>> > On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
>> >> 2012/8/28 David Fetter :
>> >> > On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
>> >> >> Kohei Kai
2012/8/28 Kohei KaiGai :
> 2012/8/28 Tom Lane :
>> Kohei KaiGai 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
>>> c
On Tue, Aug 28, 2012 at 06:08:59PM +0200, Kohei KaiGai wrote:
> 2012/8/28 David Fetter :
> > On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
> >> 2012/8/28 David Fetter :
> >> > On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
> >> >> Kohei KaiGai writes:
> >> >> > It seems
2012/8/28 David Fetter :
> On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
>> 2012/8/28 David Fetter :
>> > On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
>> >> Kohei KaiGai writes:
>> >> > It seems to me TargetEntry of the parse tree can inform us
>> >> > which column sho
2012/8/28 Tom Lane :
> Kohei KaiGai 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
On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
> 2012/8/28 David Fetter :
> > On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
> >> Kohei KaiGai writes:
> >> > It seems to me TargetEntry of the parse tree can inform us
> >> > which column should be modified on UPDATE or INS
2012/8/28 David Fetter :
> On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
>> Kohei KaiGai 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-
On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
> Kohei KaiGai 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.
Kohei KaiGai 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 triggers modifying th
Kohei KaiGai 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 stage.
It's not
2012/8/28 Albe Laurenz :
> 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,
>>>
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
2012/8/27 Shigeru HANADA :
> Kaigai-san,
>
> On Thu, Aug 23, 2012 at 2:10 PM, Kohei KaiGai 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
>> bas
2012/8/27 Albe Laurenz :
> Kohei KaiGai wrote:
>> 2012/8/25 Robert Haas :
>>> On Thu, Aug 23, 2012 at 1:10 AM, 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 maxim
Kaigai-san,
On Thu, Aug 23, 2012 at 2:10 PM, Kohei KaiGai 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.
Attached is a tar
Kohei KaiGai wrote:
> 2012/8/25 Robert Haas :
>> On Thu, Aug 23, 2012 at 1:10 AM, 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.
>> It strikes me as incredibl
2012/8/25 Robert Haas :
> On Thu, Aug 23, 2012 at 1:10 AM, 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.
>
> It strikes me as incredibly short-sighted to decide
On Thu, Aug 23, 2012 at 1:10 AM, 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.
It strikes me as incredibly short-sighted to decide that the row
identifier has to h
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
