On Sat, 1 Jan 2011 23:54:05 -0500
Robert Haas robertmh...@gmail.com 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
On Wed, Jan 5, 2011 at 19:24, Shigeru HANADA han...@metrosystems.co.jp 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
On Sat, Jan 1, 2011 at 11:54 PM, Robert Haas robertmh...@gmail.com 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
On Tue, 4 Jan 2011 22:16:26 -0500
Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 1, 2011 at 11:54 PM, Robert Haas robertmh...@gmail.com 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
On Sat, 1 Jan 2011 23:54:05 -0500
Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 27, 2010 at 10:16 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas robertmh...@gmail.com wrote:
I'm working on getting a first chunk of this committed.
OK,
On Mon, Dec 27, 2010 at 10:16 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas robertmh...@gmail.com 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
On 28.12.2010 05:16, Robert Haas wrote:
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haasrobertmh...@gmail.com 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
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 Tue, Dec 28, 2010 at 18:45, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Tue, Dec 28, 2010 at 1:52 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
On Mon, 27 Dec 2010 22:16:42 -0500
Robert Haas robertmh...@gmail.com wrote:
OK, here's the patch. Changes from the submitted fdw_syntax patch:
In psql document, I found an inconsistency between \command-letter
On Tue, Dec 28, 2010 at 4:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28.12.2010 05:16, Robert Haas wrote:
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haasrobertmh...@gmail.com
wrote:
In fact, basically all you can do with CREATE FOREIGN TABLE is set column
names,
On Tue, Dec 28, 2010 at 4:59 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas robertmh...@gmail.com 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
On Mon, 27 Dec 2010 22:16:42 -0500
Robert Haas robertmh...@gmail.com 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.
On Wed, Dec 15, 2010 at 8:25 AM, Shigeru HANADA
han...@metrosystems.co.jp 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
On Tue, 21 Dec 2010 19:33:04 +
Simon Riggs si...@2ndquadrant.com 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
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 how
On Fri, 24 Dec 2010 11:34:59 +
Simon Riggs si...@2ndquadrant.com 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
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,
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 from
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
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, otherwise
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 useful
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 of
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 reasons,
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 possible
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
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.
On Mon, 13 Dec 2010 21:51:40 -0500
Robert Haas robertmh...@gmail.com 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
On Tue, Dec 14, 2010 at 1:16 AM, Pavel Stehule pavel.steh...@gmail.com 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,
On Tue, Dec 14, 2010 at 23:38, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 14, 2010 at 1:16 AM, Pavel Stehule pavel.steh...@gmail.com
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
On Tue, Dec 14, 2010 at 9:06 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
I'll simplify the patch and post patches 1-4 of below first.
essential part
1) Basic syntax for FOREIGN TABLE and FDW HANDLER
2) FDW API and ForeignScan execution
# These patches are split just to make review
On Tue, Dec 14, 2010 at 9:42 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Tue, Dec 14, 2010 at 23:38, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 14, 2010 at 1:16 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
On the other hand, I don't really see any advantage to
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 14, 2010 at 9:42 AM, Itagaki Takahiro
itagaki.takah...@gmail.com 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
On Tue, Dec 14, 2010 at 23:45, Robert Haas robertmh...@gmail.com 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
On Wed, Dec 15, 2010 at 12:48:59AM +0900, Itagaki Takahiro wrote:
On Tue, Dec 14, 2010 at 23:45, Robert Haas robertmh...@gmail.com 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
On Tue, Dec 14, 2010 at 10:48 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Tue, Dec 14, 2010 at 23:45, Robert Haas robertmh...@gmail.com 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
2010/12/14 Shigeru HANADA han...@metrosystems.co.jp:
On Thu, 25 Nov 2010 15:03:29 +0200
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
2010/12/13 Shigeru HANADA han...@metrosystems.co.jp:
On Sun, 12 Dec 2010 23:47:53 +0200
Peter Eisentraut pete...@gmx.net 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
On Mon, Dec 13, 2010 at 10:10 AM, Shigeru HANADA
han...@metrosystems.co.jp 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
2010/12/14 Robert Haas robertmh...@gmail.com:
On Mon, Dec 13, 2010 at 10:10 AM, Shigeru HANADA
han...@metrosystems.co.jp 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
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 DATA
On Sun, 12 Dec 2010 23:47:53 +0200
Peter Eisentraut pete...@gmx.net 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
2010/11/25 Shigeru HANADA han...@metrosystems.co.jp:
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
On Wed, Dec 1, 2010 at 12:30, Hitoshi Harada umi.tan...@gmail.com 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
2010/12/1 Itagaki Takahiro itagaki.takah...@gmail.com:
On Wed, Dec 1, 2010 at 12:30, Hitoshi Harada umi.tan...@gmail.com 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
On Wed, 1 Dec 2010 12:30:46 +0900
Hitoshi Harada umi.tan...@gmail.com 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
Shigeru HANADA han...@metrosystems.co.jp 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
On Fri, Nov 26, 2010 at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Shigeru HANADA han...@metrosystems.co.jp 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
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
On Thu, Nov 25, 2010 at 22:03, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 25.11.2010 16:16, Itagaki Takahiro wrote:
On Thu, Nov 25, 2010 at 22:03, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On 25.11.2010 18:18, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On 25.11.2010 18:28, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
58 matches
Mail list logo
