On Wed, Jan 5, 2011 at 19:24, Shigeru HANADA wrote:
> 2) foreign_scan.patch includes ForeignScan executor node and
> FdwRoutine interface
I can see now Iterate() callback is called in per-tuple memory context.
I'll adjust copy from API for the change. We don't need to export the
executor state in
On Sat, 1 Jan 2011 23:54:05 -0500
Robert Haas wrote:
> Hanada-san, can you rebase the fdw_scan patch over what I committed
> and post an updated version ASAP? It'd be better for Heikki or Tom to
> work on that part of this than me, since they have a better
> understanding of the executor than I d
On Sat, 1 Jan 2011 23:54:05 -0500
Robert Haas wrote:
> On Mon, Dec 27, 2010 at 10:16 PM, Robert Haas wrote:
> > On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas wrote:
> >> I'm working on getting a first chunk of this committed.
> >
> > OK, here's the patch.
>
> I've now committed a version of thi
On Tue, 4 Jan 2011 22:16:26 -0500
Robert Haas wrote:
> On Sat, Jan 1, 2011 at 11:54 PM, Robert Haas wrote:
> > Hanada-san, can you rebase the fdw_scan patch over what I committed
> > and post an updated version ASAP? It'd be better for Heikki or Tom to
> > work on that part of this than me, sinc
On Sat, Jan 1, 2011 at 11:54 PM, Robert Haas wrote:
> Hanada-san, can you rebase the fdw_scan patch over what I committed
> and post an updated version ASAP? It'd be better for Heikki or Tom to
> work on that part of this than me, since they have a better
> understanding of the executor than I do
On Mon, Dec 27, 2010 at 10:16 PM, Robert Haas wrote:
> On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas wrote:
>> I'm working on getting a first chunk of this committed.
>
> OK, here's the patch.
I've now committed a version of this with a bunch of further
revisions, corrections, and cleanup. It l
On Tue, Dec 28, 2010 at 4:59 AM, Heikki Linnakangas
wrote:
> On 28.12.2010 05:16, Robert Haas wrote:
>> I'd appreciate some review of what's attached, even though it's not
>> totally final yet.
>
> This construct doesn't translate well:
Yeah, there are a bunch of remaining error message issues.
On Tue, Dec 28, 2010 at 4:45 AM, Heikki Linnakangas
wrote:
> On 28.12.2010 05:16, Robert Haas wrote:
>> On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas
>> wrote:
>> In fact, basically all you can do with CREATE FOREIGN TABLE is set column
>> names, types, and whether they're NOT NULL. But I think
On Tue, Dec 28, 2010 at 1:52 AM, Shigeru HANADA
wrote:
> On Mon, 27 Dec 2010 22:16:42 -0500
> Robert Haas wrote:
>> OK, here's the patch. Changes from the submitted fdw_syntax patch:
>
> In psql document, I found an inconsistency between \command-letter and
> object-type has been in the original
On Tue, Dec 28, 2010 at 18:45, Heikki Linnakangas
wrote:
>> In fact, basically all you can do with CREATE FOREIGN TABLE is set column
>> names, types, and whether they're NOT NULL. But I think that's enough
>> to get started.
>
> Even NOT NULL seems questionable. It might be interesting for the p
On 28.12.2010 05:16, Robert Haas wrote:
I'd appreciate some review of what's attached, even though it's not
totally final yet.
This construct doesn't translate well:
+ appendStringInfo(&allowed, "table%s%s%s",
+ allowView ? " or view" : "",
+
On 28.12.2010 05:16, Robert Haas wrote:
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas wrote:
In fact, basically all you can do with CREATE FOREIGN TABLE is set column
names, types, and whether they're NOT NULL. But I think that's enough
to get started.
Even NOT NULL seems questionable. It mig
On Mon, 27 Dec 2010 22:16:42 -0500
Robert Haas wrote:
> OK, here's the patch. Changes from the submitted fdw_syntax patch:
In psql document, I found an inconsistency between \command-letter and
object-type has been in the original patch. Attached patch would fix
it.
Regards,
--
Shigeru Hanada
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas wrote:
> I'm working on getting a first chunk of this committed.
OK, here's the patch. Changes from the submitted fdw_syntax patch:
- I removed a LOT of frammishes from CREATE FOREIGN TABLE. I think
that the idea of letting foreign tables inherit f
On Wed, Dec 15, 2010 at 8:25 AM, Shigeru HANADA
wrote:
> In order to make review easier, fdw_core patch has been split into
> two parts, fdw_syntax and fdw_scan. Please apply fdw_scan onto
> fdw_syntax to test whole features.
I'm working on getting a first chunk of this committed. I've removed
On Fri, 24 Dec 2010 11:34:59 +
Simon Riggs wrote:
> On Fri, 2010-12-24 at 19:51 +0900, Shigeru HANADA wrote:
> > > 15. In terms of planning queries, do we have a concept of additional
> > > cost per row on a foreign server? How does the planner decide how
> > costly
> > > retrieving data is fr
Thank you for those replies, I understand things much better now.
I have two remaining concerns...
On Fri, 2010-12-24 at 19:51 +0900, Shigeru HANADA wrote:
> > 15. In terms of planning queries, do we have a concept of additional
> > cost per row on a foreign server? How does the planner decide ho
On Tue, 21 Dec 2010 19:33:04 +
Simon Riggs wrote:
> 1. The docs don't actually say what a foreign table is. Is it a local
> representation of foreign data? Or a local copy of foreign data? Or is
> it a table created on a remote node?
"Foreign table" is an database object which represents the
On Wed, 2010-12-22 at 07:36 -0800, David Fetter wrote:
> >
> > > > 7. Why does ANALYZE skip foreign tables? Surely its really
> > > > important we know things about a foreign table, otherwise we are
> > > > going to optimize things very badly.
> > >
> > > Quite apart from other reasons, such as p
On Wed, Dec 22, 2010 at 12:54:06PM -0300, Alvaro Herrera wrote:
> Excerpts from David Fetter's message of mié dic 22 12:36:10 -0300 2010:
> > On Wed, Dec 22, 2010 at 03:00:16PM +, Simon Riggs wrote:
> > > On Wed, 2010-12-22 at 09:03 -0500, Andrew Dunstan wrote:
>
> > > > Quite apart from other
Excerpts from David Fetter's message of mié dic 22 12:36:10 -0300 2010:
> On Wed, Dec 22, 2010 at 03:00:16PM +, Simon Riggs wrote:
> > On Wed, 2010-12-22 at 09:03 -0500, Andrew Dunstan wrote:
> > > Quite apart from other reasons, such as possible ephemerality of
> > > the data, the difficulty
On Tue, Dec 21, 2010 at 07:33:04PM +, Simon Riggs wrote:
> On Wed, 2010-12-15 at 22:25 +0900, Shigeru HANADA wrote:
>
> > Attached are revised version of SQL/MED core functionality patches.
>
> Looks very interesting new feature, well done.
While, "read SQL:2008" is generally not super usefu
On Wed, Dec 22, 2010 at 03:00:16PM +, Simon Riggs wrote:
> On Wed, 2010-12-22 at 09:03 -0500, Andrew Dunstan wrote:
>
> > Answering a few of your questions
>
> Many thanks.
>
> > > 7. Why does ANALYZE skip foreign tables? Surely its really
> > > important we know things about a foreign table
On 12/22/2010 10:00 AM, Simon Riggs wrote:
7. Why does ANALYZE skip foreign tables? Surely its really important we
know things about a foreign table, otherwise we are going to optimize
things very badly.
Quite apart from other reasons, such as possible ephemerality of the
data, the difficulty
On Wed, 2010-12-22 at 09:03 -0500, Andrew Dunstan wrote:
> Answering a few of your questions
Many thanks.
> > 7. Why does ANALYZE skip foreign tables? Surely its really important we
> > know things about a foreign table, otherwise we are going to optimize
> > things very badly.
>
> Quite apart
On 12/21/2010 02:33 PM, Simon Riggs wrote:
On Wed, 2010-12-15 at 22:25 +0900, Shigeru HANADA wrote:
Attached are revised version of SQL/MED core functionality patches.
Looks very interesting new feature, well done.
Can I ask some questions about how this will work?
No particular order, just
On Wed, 2010-12-15 at 22:25 +0900, Shigeru HANADA wrote:
> Attached are revised version of SQL/MED core functionality patches.
Looks very interesting new feature, well done.
Can I ask some questions about how this will work?
No particular order, just numbered for reference.
1. The docs don't ac
On Tue, Dec 14, 2010 at 10:48 AM, Itagaki Takahiro
wrote:
> On Tue, Dec 14, 2010 at 23:45, Robert Haas wrote:
>>> We need RULEs or INSTEAD OF TRIGGERs to support updatable foreign tables.
>>
>> We do? Why can't the support for updating foreign tables be built-in
>> rather than trigger-based?
>
>
On Wed, Dec 15, 2010 at 12:48:59AM +0900, Itagaki Takahiro wrote:
> On Tue, Dec 14, 2010 at 23:45, Robert Haas wrote:
> >> We need RULEs or INSTEAD OF TRIGGERs to support updatable foreign
> >> tables.
> >
> > We do? Why can't the support for updating foreign tables be
> > built-in rather than tr
On Tue, Dec 14, 2010 at 23:45, Robert Haas wrote:
>> We need RULEs or INSTEAD OF TRIGGERs to support updatable foreign tables.
>
> We do? Why can't the support for updating foreign tables be built-in
> rather than trigger-based?
Do we have any concrete idea for the built-in update feature?
There
Robert Haas writes:
> On Tue, Dec 14, 2010 at 9:42 AM, Itagaki Takahiro
> wrote:
>> We need RULEs or INSTEAD OF TRIGGERs to support updatable foreign tables.
> We do? Why can't the support for updating foreign tables be built-in
> rather than trigger-based?
It *has* to be built in. What exact
On Tue, Dec 14, 2010 at 9:42 AM, Itagaki Takahiro
wrote:
> On Tue, Dec 14, 2010 at 23:38, Robert Haas wrote:
>> On Tue, Dec 14, 2010 at 1:16 AM, Pavel Stehule
>> wrote:
On the other hand, I don't really see any advantage to allowing rules
on foreign tables - ever. Unless there's some
On Tue, Dec 14, 2010 at 9:06 AM, Shigeru HANADA
wrote:
> I'll simplify the patch and post patches 1-4 of below first.
>
>
> 1) Basic syntax for FOREIGN TABLE and FDW HANDLER
> 2) FDW API and ForeignScan execution
> # These patches are split just to make review easy.
>
>
> 3) pgsql_fdw
> 4) file_
On Tue, Dec 14, 2010 at 23:38, Robert Haas wrote:
> On Tue, Dec 14, 2010 at 1:16 AM, Pavel Stehule
> wrote:
>>> On the other hand, I don't really see any advantage to allowing rules
>>> on foreign tables - ever. Unless there's some reason we really need
>>> that, my gut feeling would be to rip
On Tue, Dec 14, 2010 at 1:16 AM, Pavel Stehule wrote:
>> On the other hand, I don't really see any advantage to allowing rules
>> on foreign tables - ever. Unless there's some reason we really need
>> that, my gut feeling would be to rip it out and forget about it.
>
> views, updateable views?
W
On Mon, 13 Dec 2010 21:51:40 -0500
Robert Haas wrote:
> This actually doesn't apply cleanly. There's a hunk in pg_class.h
> that is failing.
I might have missed recent changes about pg_class.relistemp.
I've fixed in local repo.
> I think attgenoptions is a poor choice of name for the concept it
On mån, 2010-12-13 at 14:45 +0900, Shigeru HANADA wrote:
> Simple FDWs such as File FDW might not have concept of "user" on
> remote side. In such case, it would be enough to control access
> privilege per local user with GRANT/REVOKE SELECT statement.
Right. But it depends on the implementation
2010/12/14 Robert Haas :
> On Mon, Dec 13, 2010 at 10:10 AM, Shigeru HANADA
> wrote:
>> I've revised fdw_core patch along your proposal and subsequent
>> discussion, and tried to fix FDW patches pgsql_fdw and file_fdw
>> according to fdw_core. Attached is a WIP which includes changes
>> below.
>
On Mon, Dec 13, 2010 at 10:10 AM, Shigeru HANADA
wrote:
> I've revised fdw_core patch along your proposal and subsequent
> discussion, and tried to fix FDW patches pgsql_fdw and file_fdw
> according to fdw_core. Attached is a WIP which includes changes
> below.
This actually doesn't apply cleanl
2010/12/13 Shigeru HANADA :
> On Sun, 12 Dec 2010 23:47:53 +0200
> Peter Eisentraut wrote:
>> On ons, 2010-12-01 at 12:30 +0900, Hitoshi Harada wrote:
>> > From a user's view, this is very long way to see a simplest foreign
>> > table. I know it is based on the standard, but I really want a
>> > s
2010/12/14 Shigeru HANADA :
> On Thu, 25 Nov 2010 15:03:29 +0200
> Heikki Linnakangas wrote:
>> I propose the attached API instead. This has a clear separation between
>> plan and execution. I'm sure we'll have to extend the API in the future
>> FDWs want tighter integration, but I think this is a
On Sun, 12 Dec 2010 23:47:53 +0200
Peter Eisentraut wrote:
> On ons, 2010-12-01 at 12:30 +0900, Hitoshi Harada wrote:
> > From a user's view, this is very long way to see a simplest foreign
> > table. I know it is based on the standard, but I really want a
> > shortcut. Especially, I don't underst
On ons, 2010-12-01 at 12:30 +0900, Hitoshi Harada wrote:
> I've tried SQL/MED with postgresql_fdw last night, and found myself
> confusing the long setup procedure. A simplest way to use it AFAIK is:
>
> 1.CREATE FOREIGN DATA WRAPPER ... (or run install sql script)
> 2.CREATE SERVER ... FOREIGN DA
On Wed, 1 Dec 2010 12:30:46 +0900
Hitoshi Harada wrote:
> This is another topic, but it would be useful if CREATE FOREIGN TABLE
> can omit column definitions since fdw usually knows what should be
> there in the definitions. I some times mistyped the column names
> between remote and local and res
2010/12/1 Itagaki Takahiro :
> On Wed, Dec 1, 2010 at 12:30, Hitoshi Harada wrote:
>> From a user's view, this is very long way to see a simplest foreign
>> table. I know it is based on the standard, but I really want a
>> shortcut. Especially, I don't understand why CREATE USER MAPPING FOR
>> cur
On Wed, Dec 1, 2010 at 12:30, Hitoshi Harada wrote:
> From a user's view, this is very long way to see a simplest foreign
> table. I know it is based on the standard, but I really want a
> shortcut. Especially, I don't understand why CREATE USER MAPPING FOR
> current_user SERVER is needed for def
2010/11/25 Shigeru HANADA :
> Hi hackers,
>
> Attached is a patch that adds core functionality of SQL/MED. This
> patch provides:
>
> "SQL/MED - file_fdw" : FDW for external PostgreSQL
> "SEL/MED - postgresql_fdw" : FDW for server-side file (CSV, TEXT)
>
I've tried SQL/MED with postgr
On Fri, Nov 26, 2010 at 11:16 AM, Tom Lane wrote:
> Shigeru HANADA writes:
>> I'll revise the patch along the discussion. Before starting code work,
>> please let me summarize the discussion.
>
>> * Generally, we should keep FDWs away from PostgreSQL internals,
>> such as TupleTableSlot.
>
>> *
Shigeru HANADA writes:
> I'll revise the patch along the discussion. Before starting code work,
> please let me summarize the discussion.
> * Generally, we should keep FDWs away from PostgreSQL internals,
> such as TupleTableSlot.
> * FDW should have planner hook which allows FDW to create FDW-
Thanks for the comments.
I'll revise the patch along the discussion. Before starting code work,
please let me summarize the discussion.
* Generally, we should keep FDWs away from PostgreSQL internals,
such as TupleTableSlot.
* FDW should have planner hook which allows FDW to create FDW-specifi
Heikki Linnakangas writes:
> On 25.11.2010 18:28, Tom Lane wrote:
>> Or just specify a format for the extra information. Perhaps it could be
>> thought of as being a value of type bytea? Obviously we can't just have
>> a fixed amount of info, but maybe a blob with a length word is enough.
> Tha
On 25.11.2010 18:28, Tom Lane wrote:
Heikki Linnakangas writes:
Hmm, I see, cached plans are planned in a shorter-lived context first,
and copied to permanent storage afterwards. Needs more thought then.
Maybe the FDW needs to provide a copyFdwPlan() function to copy FdwPlans
returned by that F
Heikki Linnakangas writes:
> Hmm, I see, cached plans are planned in a shorter-lived context first,
> and copied to permanent storage afterwards. Needs more thought then.
> Maybe the FDW needs to provide a copyFdwPlan() function to copy FdwPlans
> returned by that FDW.
Or just specify a format
On 25.11.2010 18:18, Tom Lane wrote:
Heikki Linnakangas writes:
I left out some details on what exactly FdwPlan should contain and what
it's lifecycle should be. I'm thinking that it should be allocated in
the CurrentMemoryContext that's active when the FDW Plan routine is
called, which would b
Heikki Linnakangas writes:
> I left out some details on what exactly FdwPlan should contain and what
> it's lifecycle should be. I'm thinking that it should be allocated in
> the CurrentMemoryContext that's active when the FDW Plan routine is
> called, which would be the same context where we s
On 25.11.2010 16:16, Itagaki Takahiro wrote:
On Thu, Nov 25, 2010 at 22:03, Heikki Linnakangas
wrote:
I propose the attached API instead. This has a clear separation between plan
and execution.
The APIs seem to be cleaner. The previous ones might be too straight
implementation of the SQL sta
On Thu, Nov 25, 2010 at 22:03, Heikki Linnakangas
wrote:
> I propose the attached API instead. This has a clear separation between plan
> and execution.
The APIs seem to be cleaner. The previous ones might be too straight
implementation of the SQL standard.
But I have some questions about the ne
On 25.11.2010 09:34, Shigeru HANADA wrote:
Attached is a patch that adds core functionality of SQL/MED. This
patch provides:
* new option HANDLER for FOREIGN DATA WRAPPER
* CREATE/ALTER DDLs are supported
* psql \dew command shows handler option too
* pg_dump can dump HANDLER option
*
58 matches
Mail list logo
