On Tue, 23 Nov 2010 10:22:02 -0800
Joshua D. Drake j...@commandprompt.com wrote:
On Tue, 2010-11-23 at 20:18 +0200, Heikki Linnakangas wrote:
On 23.11.2010 14:22, Shigeru HANADA wrote:
OID is supported to get oid from the source table (yes, it works only
for postgresql_fdw but it seems
On 23.11.2010 12:09, Shigeru HANADA wrote:
On Sun, 21 Nov 2010 21:16:05 -0500
Robert Haasrobertmh...@gmail.com wrote:
snip
Ultimately, we probably want and need to get this patch down to chunks
of less than 2000 lines each. But for starters, it looks quite simple
to break this into three
On Tue, 23 Nov 2010 12:30:52 +0200
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
The docs need some work. The CREATE FOREIGN TABLE reference page seems
to be copy-pasted from CREATE TABLE, because it talks about constraints
and WITH/WITHOUT OIDS which surely don't apply to
On 23.11.2010 14:22, Shigeru HANADA wrote:
On Tue, 23 Nov 2010 12:30:52 +0200
Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote:
The docs need some work. The CREATE FOREIGN TABLE reference page seems
to be copy-pasted from CREATE TABLE, because it talks about constraints
and
On Tue, 2010-11-23 at 20:18 +0200, Heikki Linnakangas wrote:
On 23.11.2010 14:22, Shigeru HANADA wrote:
OID is supported to get oid from the source table (yes, it works only
for postgresql_fdw but it seems useful to support).
I don't think that's worthwhile. Oids on user tables is a
On Tue, Nov 23, 2010 at 5:09 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
I've separated the patch into tree parts. They have codes, documents
and tests within, and file_fdw and pgsql_fdw can be applied onto
fdw_core for each, or together. I hope the separation helps the
review of the
On Fri, Nov 19, 2010 at 9:55 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
[ new SQL/MED patch ]
I can't help noticing that this patch adds 8,982 lines and removes
408, making it far larger any other patch I've ever seen on this list.
And what that means is that committing all of this in
On Mon, Nov 22, 2010 at 11:16, Robert Haas robertmh...@gmail.com wrote:
To have a chance of getting a significant portion
of this into PostgreSQL 9.1, it really needs to be broken up into
INDEPENDENTLY COMMITTABLE SUB-PATCHES.
Did we discuss about syntax-only patch is not acceptable because
it
On Sun, Nov 21, 2010 at 10:14 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Nov 22, 2010 at 11:16, Robert Haas robertmh...@gmail.com wrote:
To have a chance of getting a significant portion
of this into PostgreSQL 9.1, it really needs to be broken up into
INDEPENDENTLY
Some random comments on the patch:
ReleaseConnection is a very generic name for a global function, would be
good to prefix it with pgsqlfdw or something. Same with any other
globally visible functions.
Please use the built-in contain_mutable_functions(Node *) instead of
custom
Thanks for the information about Informix VTI. Because I'm not
familiar to Informix, I might have missed your point. Would you mind
telling me more about Informix VTI?
On Mon, 15 Nov 2010 08:45:14 -0800
Eric Davies e...@barrodale.com wrote:
With Informix VTI, indexing is the same for native
At 01:36 AM 11/16/2010, Shigeru HANADA wrote:
Thanks for the information about Informix VTI. Because I'm not
familiar to Informix, I might have missed your point. Would you mind
telling me more about Informix VTI?
On Mon, 15 Nov 2010 08:45:14 -0800
Eric Davies e...@barrodale.com wrote:
Thanks for the additional information!
On Tue, 16 Nov 2010 09:31:43 -0800
Eric Davies e...@barrodale.com wrote:
At 01:36 AM 11/16/2010, Shigeru HANADA wrote:
On Mon, 15 Nov 2010 08:45:14 -0800
Eric Davies e...@barrodale.com wrote:
ISTM that index on a VTI table could be inconsistent when
With Informix VTI, indexing is the same for native tables as for
virtual tables, except the interpretation of the 32 bit rowid is left
up to the developer. When you define the VTI class, you optionally
supply a method that can fetch data based on a 32 bit rowid, and it's
the responsibility of
On Fri, 12 Nov 2010 08:27:54 -0800
Eric Davies e...@barrodale.com wrote:
Thank you for the time estimate and the interface discussion. It
sounds like the PostgreSQL SQL/MED code will be very useful when it
is done. Our product provides read-only access to files, so
updates/inserts/deletes
On Mon, Nov 15, 2010 at 12:41, Shigeru HANADA han...@metrosystems.co.jp wrote:
No, SQL/MED would not support indexing foreign tables, at least in
first version. Because it would be difficult to use common row id for
various FDWs.
I think the reason is the SQL standard never mention about
Hi Gentlemen,
Thank you for the time estimate and the interface discussion. It
sounds like the PostgreSQL SQL/MED code will be very useful when it
is done. Our product provides read-only access to files, so
updates/inserts/deletes aren't an issue for us.
One thing that is not clear to me is
On Sat, 6 Nov 2010 16:04:37 +0900
Hitoshi Harada umi.tan...@gmail.com wrote:
2010/11/5 Shigeru HANADA han...@metrosystems.co.jp:
On Fri, 5 Nov 2010 16:27:49 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
PL/Proxy has a similar functionality with RUN ON ALL to start queries
in
Shigeru HANADA han...@metrosystems.co.jp writes:
How about removing them, ConnectServer and FreeFSConnection, from
FdwRoutine and leaving the responsibility of resource management to
each FDW? Each FDW would have to use mechanism such as Virtual File
and ResourceOwner to manage resources
On Fri, 05 Nov 2010 10:43:45 -0400
Tom Lane t...@sss.pgh.pa.us wrote:
Shigeru HANADA han...@metrosystems.co.jp writes:
Thanks, now I see your point. Current FdwRoutine has no appropriate
function because Open is called from ExecutorStart which is used by
EXPLAIN too.
But then we have
2010/11/5 Shigeru HANADA han...@metrosystems.co.jp:
On Fri, 5 Nov 2010 16:27:49 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
PL/Proxy has a similar functionality with RUN ON ALL to start queries
in parallel. So, I think it's a infrastructure commonly required.
I noticed the lack
Hitoshi Harada umi.tan...@gmail.com writes:
And if we really make this async query come true, I suggest designing
resource (i.e. remote connection) management very carefully. When the
executor fails in the middle of its execution, it possibly fails to
release its own resource; close() in
On Thu, 4 Nov 2010 18:22:52 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Thu, Nov 4, 2010 at 6:04 PM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
For example:
* PRIMARY ACCESS_METHOD - HANDLER of FOREIGN DATA WRAPPER
* am_scancost() - FdwRoutine.EstimateCosts()
On Fri, Nov 5, 2010 at 4:00 PM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
* am_beginscan() - first call of FdwRoutine.Iterate()?
It might be good to have a separated beginscan method if we use
asynchronous scans in multiple foreign servers in one query
You mean that separated
On Fri, 5 Nov 2010 16:27:49 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Fri, Nov 5, 2010 at 4:00 PM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
* am_beginscan() - first call of FdwRoutine.Iterate()?
It might be good to have a separated beginscan method if we use
Shigeru HANADA han...@metrosystems.co.jp writes:
Thanks, now I see your point. Current FdwRoutine has no appropriate
function because Open is called from ExecutorStart which is used by
EXPLAIN too.
But then we have mismatch between executor node interface and FDW
interface about BeginScan.
On Wed, 03 Nov 2010 13:32:18 -0700
Eric Davies e...@barrodale.com wrote:
On Informix, we were able to take advantage of the VTI (Virtual Table
Interface) feature to support table scans and indexing. (See
http://www.ibm.com/developerworks/data/zones/informix/library/techarticle/db_vti.html
On Thu, Nov 4, 2010 at 6:04 PM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
For example:
* PRIMARY ACCESS_METHOD - HANDLER of FOREIGN DATA WRAPPER
* am_scancost() - FdwRoutine.EstimateCosts()
* am_open() - FdwRoutine.Open()
* am_beginscan() - first call of
28 matches
Mail list logo
