- Invalid item names properly cause error.
* I'm not so familiar to pl/pgsql, but ISTM that enough cases are
considered about newly added diagnostics items.
* I didn't see any crash during my tests.
In conclusion, this patch still needs some effort to be "Ready for
Committer",
(2011/07/04 10:17), Shigeru Hanada wrote:
> (2011/07/03 18:50), Kohei KaiGai wrote:
>> I checked the per-column generic option patch.
>> Right now, I have nothing to comment on anymore.
>> So, it should be reviewed by committers.
>
> Thanks for the review!.
I w
(2011/07/03 18:50), Kohei KaiGai wrote:
> I checked the per-column generic option patch.
> Right now, I have nothing to comment on anymore.
> So, it should be reviewed by committers.
Thanks for the review!.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsq
aybe such error usually
happens and is visible to users. This criteria was taken from the
document "Reporting Errors Within the Server".
http://developer.postgresql.org/pgdocs/postgres/error-message-reporting.html
Regards,
--
Shigeru Hanada
diff --git a/contrib/file_fdw/file_fdw.c b
Sorry for the long delay...
(2011/06/17 21:59), David Fetter wrote:
> On Fri, Jun 17, 2011 at 07:19:39PM +0900, Shigeru Hanada wrote:
>> (2011/06/17 8:44), David Fetter wrote:
>>> Sorry not to respond sooner.
>>>
>>> First, the per-column generic options
(2011/06/24 19:14), HuangQi wrote:
> 2011/6/24 Shigeru Hanada
>
>> (2011/06/24 15:35), HuangQi wrote:
>> ex)
>> elog(DEBUG1, "%s", nodeToString(plan));
>
> Hi,
> I don't know why but when I am debugging the query evaluation, the elog
&
;s applicable for any Node-derived
object, such as Expr, Var and Const.
ex)
elog(DEBUG1, "%s", nodeToString(plan));
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of data type
mapping setting, or mapping definition itself, right? If so, a foreign
table needs to be created to use per-column FDW options. Does it suit
to your idea?
BTW, I couldn't get what you mean by "dependency tracking". You mean
the dependency between foreign column and l
y non-superuser.
The patch produces no compiler warning for both binaries and documents.
Architecture review
===
AFAICS, this patch adopts the GUC parameter's standards.
Regards,
--
Shigeru Hanada
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index e83
is post... I'm going to
work on this and post revised patch soon. Please examine other parts first.
Documents
~
1) Is "generic options" proper term to mean FDW-specific option
associated to a FDW object? It's used in the SQL/MED standard, but
seems not popular... "FD
cle. I'm planning to start major pgsql_fdw work after CF
2011-06, and before that I'm going to work on some common SQL/MED issues
such as per-column options and table inheritance.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Thanks for the review.
(2011/06/12 13:21), Robert Haas wrote:
> 2011/6/9 Shigeru Hanada:
>> Attached patch includes fixes for FOREIGN TABLE documents:
>
> I committed the changes to ALTER FOREIGN TABLE, but I think the
> changes to CREATE FOREIGN TABLE need more thought. The
in the thread:
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01949.php
Regards,
--
Shigeru Hanada
diff --git a/doc/src/sgml/ref/alter_foreign_table.sgml
b/doc/src/sgml/ref/alter_foreign_table.sgml
index c2ebdac..af7d5fa 100644
*** a/doc/src/sgml/ref/alter_foreign_table.sg
are
visible to users who have any privileges on the foreign table.
Regards,
--
Shigeru Hanada
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index 93e8332..689aba5 100644
*** a/doc/src/sgml/ref/grant.sgml
--- b/doc/src/sgml/ref/grant.sgml
*** GRANT rol
REATE TABLE
postgres=# ALTER FOREIGN TABLE foo RENAME TO bar;
ERROR: "foo" is not a foreign table
HINT: Use ALTER FOREIGN TABLE instead.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
file_server;
postgres=# ALTER FOREIGN TABLE foo RENAME TO bar;
ERROR: "foo" is not a foreign table
HINT: Use ALTER FOREIGN TABLE instead.
Regards,
--
Shigeru Hanada
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 7660114..09f3f4e 100644
*** a/src/backen
I found that DROP OWNED BY can cause $SUBJECT.
How to reproduce the error:
CREATE USER foo;
ALTER DEFAULT PRIVILEGES GRANT ALL ON SEQUENCES TO foo;
DROP OWNED BY foo;
Attached patch would fix this issue.
Regards,
--
Shigeru Hanada
diff --git a/src/backend/catalog/aclchk.c b/src
(2011/04/15 3:43), Robert Haas wrote:
On Fri, Apr 1, 2011 at 1:29 AM, Shigeru HANADA
wrote:
In addition to the 2nd GRANT above, "GRANT SELECT (colour) ON stuff TO
user_a" (omitting TABLE) will succeed too because parser assumes that
the target object is a regular table if objec
ERT, pg_lesslog generates incremental logs
such as xl_heap_header and tuple image from the inserted tuple in the
full-page image, and replaces full-page image with them.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On Tue, 05 Apr 2011 13:37:48 +0900
Shigeru HANADA wrote:
> On Mon, 4 Apr 2011 12:47:18 -0400
> Robert Haas wrote:
> > BTW, I think you can merge patches 0001 to 0004 into a single patch.
>
> They were separated just for review, so I'll post revised and unified
>
Thanks for the review.
On Mon, 4 Apr 2011 12:47:18 -0400
Robert Haas wrote:
> On Mon, Apr 4, 2011 at 6:49 AM, Shigeru HANADA
> wrote:
> > 1) Who can comment on a user mapping?
> > Basically only the owner can comment on a object, but user mappings
> > don't have o
On Sun, 3 Apr 2011 10:51:04 +0900
Shigeru Hanada wrote:
> 2011/4/2 Robert Haas :
> > On Fri, Apr 1, 2011 at 11:57 AM, Thom Brown wrote:
> >> Should we also have support for comments on user mappings?
> >
> > Oh, bugger. Yeah, probably.
>
> I'd work
2011/4/2 Robert Haas :
> On Fri, Apr 1, 2011 at 11:57 AM, Thom Brown wrote:
>> Should we also have support for comments on user mappings?
>
> Oh, bugger. Yeah, probably.
I'd work on this, if taking some days is OK.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers
REATE TABLE with serial column is transformed into 3 DDLs:
(1) CREATE SEQUENCE, for serial column
(2) CREATE TABLE, skipped if table exists with same name
(3) ALTER SEQUENCE OWNED BY, associate sequence with table
This error occurs in (3) because process_owned_by() misunderstand
th
CL_OBJECT_FOREIGN_TABLE),
but it wouldn't be problem because object type will be retrieved in
ExecGrant_Relation() for validate privilege type.
Probabry we should mention in GRANT documents that ALL TABLES
IN SCHEMA is considered to include foreign tables.
Attached patch includes removin
I noticed that CREATE FOREIGN TABLE document would need some
corrections.
- server_name is not mentioned in Parameters section
- "=" is unnecessary in OPTIONS
Please find attached a brief patch.
Regards,
--
Shigeru Hanada
create_foreign_table_doc.patch
Description: Binary data
2.
I'm working on it.
Fixes for new FDW API have been done, but there are some problems in
SQL generation codes, such as SELECT clause optimization (omitting
unused column from SELECT clause). It would take a while, but I'll
post revised version of the patch tomorrow.
Regards,
--
Shige
On Wed, 16 Feb 2011 16:48:33 +0900
Itagaki Takahiro wrote:
> On Tue, Feb 8, 2011 at 00:30, Shigeru HANADA
> wrote:
> > Fixed version is attached.
>
> I reviewed your latest git version, that is a bit newer than the attached
> patch.
> http://git.postgresql.o
e/hanada/DB/BINARY/branches.bin' with binary;
COPY 9187201950435737481
It would be because DR_copy's processed is not initialized in
CreateCopyDestReceiver(). Please see attached patch.
Regards,
--
Shigeru Hanada
20110218_initialize_processed.patch
Description: Binary data
--
Sent vi
On Tue, 8 Feb 2011 08:49:36 -0500
Robert Haas wrote:
> On Tue, Feb 8, 2011 at 4:42 AM, Shigeru HANADA
> wrote:
> > I'll submit revised file_fdw patch after removing IsForeignTable()
> > catalog lookup along Heikki's proposal.
>
> So I'm a bit confused.
On Mon, 07 Feb 2011 09:37:37 +0100
Heikki Linnakangas wrote:
> On 07.02.2011 08:00, Shigeru HANADA wrote:
> > Sorry for late, attached are revised version of FDW API patches which
> > reflect Heikki's comments except removing catalog lookup via
> > IsForeignTable(
reaind/reading/
Recent file_fdw is available here:
http://git.postgresql.org/gitweb?p=users/hanada/postgres.git;a=summary
I'll submit revised file_fdw patch after removing IsForeignTable()
catalog lookup along Heikki's proposal.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailin
On Mon, 7 Feb 2011 21:00:53 +0900
Itagaki Takahiro wrote:
> On Mon, Feb 7, 2011 at 16:01, Shigeru HANADA
> wrote:
> > This patch is based on latest FDW API patches which are posted in
> > another thread "SQL/MED FDW API", and copy_export-20110104.patch which
&
sed version of file_fdw patch.
This patch is based on latest FDW API patches which are posted in
another thread "SQL/MED FDW API", and copy_export-20110104.patch which
was posted by Itagaki-san.
Regards,
--
Shigeru Hanada
file_fdw.patch.gz
Description: Binary data
--
Sent via pgsql-hac
On Mon, 31 Jan 2011 22:00:55 +0900
Shigeru HANADA wrote:
> I'll post FDW API patches which reflect comments first, and then I'll
> rebase postgresql_fdw against them.
Sorry for late, attached are revised version of FDW API patches which
reflect Heikki's comments except re
35. Extending SQL"?
> In general, I think the design is sound. What we need is more
> documentation. It'd also be nice to see the postgresql_fdw brought back
> to shape so that it works against this latest version of the api patch.
I'll post FDW API patches which reflect comments first, and then I'll
rebase postgresql_fdw against them.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, 21 Jan 2011 18:28:19 +0200
Heikki Linnakangas wrote:
> On 18.01.2011 17:26, Shigeru HANADA wrote:
> > 3) 20110118-fdw_handler.patch - This patch adds support for HANDLER
> > option to FOREIGN DATA WRAPPER object.
>
> Some quick comments on that:
Thanks for th
On Thu, 20 Jan 2011 22:21:37 +0900
Itagaki Takahiro wrote:
> On Wed, Jan 19, 2011 at 00:34, Shigeru HANADA
> wrote:
> > Attached patch requires FDW API patches and copy_export-20110114.patch.
>
> Some minor comments:
Thanks for the comments.
I'll post revised version of
On Tue, 18 Jan 2011 15:17:12 +0900
Itagaki Takahiro wrote:
> On Sat, Jan 15, 2011 at 08:35, Shigeru HANADA
> wrote:
> > Interface of NextCopyFrom() is fixed to return HeapTuple, to support
> > tableoid without any change to TupleTableSlot.
> >
> > 3) 20110
got a segfault
> when EndScan tried to free things that BeginScan allocated. Maybe just
> don't call EndScan for EXPLAIN?
Fixed to not call EndScan if it was EXPLAIN execution.
Regards,
--
Shigeru Hanada
20110118-no_fdw_perm_check.patch.gz
Description: Binary data
20110118-fdw_catalog_
On Mon, 17 Jan 2011 22:13:19 +0900
Shigeru HANADA wrote:
> Fixed in attached patch.
Sorry, I have not attached patch to last message.
I'll post revised patch in next message soon.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
haps it
> should be available at some other, earlier stage. Second of all, what
> would it be useful for anyway? Neither file_fdw nor my commitfest_fdw
> does anything with it.
ParamListInfo is added to pass parameters of PREPARE/EXECUTE statement
to FDWs.
Plan for a prepared query is gener
On Fri, 14 Jan 2011 14:59:00 -0500
Andrew Dunstan wrote:
> Have you actually posted this version of file_fdw? I haven't seen it.
Sorry, now it's been posted.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg01205.php
Regarads,
--
Shigeru Hanada
--
Sent via pgsql-hackers
On Fri, 14 Jan 2011 14:20:20 +0900
Shigeru HANADA wrote:
> On Fri, 14 Jan 2011 13:03:27 +0900
> Itagaki Takahiro wrote:
>
> > Good catch. I merged your fix into the attached patch.
>
> Thanks, I'll rebase my patches.
I've rebased WIP patches for file_fdw onto I
assumed to
be used by FDWs.
You would be able to test these patches with "20110114" version of file_fdw
wrapper patches which will be posted in another thread.
Regards,
--
Shigeru Hanada
20110114-fdw_handler.patch.gz
Description: Binary data
20110114-foreign_scan.patch.gz
Description: B
execute "SELECT * FROM foreign_table LIMIT sample_num" internally to
get sample rows.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
w about to implement using materialized tuples to avoid unnecessary
(at least for functionality) changes. I would like to send this
virtual-tuple-optimization to next development cycle because it would
not effect the interface heavily. I'll post materialized-tuple
version of foreign_scan patch
(),
GetForeignServer(), and GetUserMapping(). This function is assumed to
be used by FDWs.
You would be able to test these patches with file_fdw wrapper which
would be posted in another thread.
Regards,
--
Shigeru Hanada
fdw_handler.patch.gz
Description: Binary data
foreign_scan.patch.gz
On Tue, 11 Jan 2011 13:24:33 +0100
Magnus Hagander wrote:
> Aha. Thanks for the pointers, pfa a new version.
Changing pg_stat replication view would require to fix regression test
"rule". Please find attached patch.
Regards,
--
Shigeru Hanada
rule_test.patch
Description: Binary d
On Mon, 10 Jan 2011 19:26:11 -0500
Tom Lane wrote:
> Shigeru HANADA writes:
> > For the purpose of file_fdw, additional ResetCopyFrom() would be
> > necessary. I'm planning to include such changes in file_fdw patch.
> > Please find attached partial patch for
this design, caller can receive results with tts_values/tts_isnull
arrays.
Regards,
--
Shigeru Hanada
20110110-ResetCopyFrom.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ATE/ALTER
FOREIGN DATA WRAPPER
2) foreign_scan.patch includes ForeignScan executor node and
FdwRoutine interface
Regards,
--
Shigeru Hanada
20110105-fdw_handler.patch.gz
Description: Binary data
20110105-foreign_scan.patch.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsq
ecute are implementation-defined.
Sorry, this problem comes from original patch.
OTOH, the document about this specification which is written in "GRANT"
page is correct.
Regards,
--
Shigeru Hanada
20110105-no_fdw_check.patch
Description: Binary data
--
Sent via pgsql-hackers
for late replyl, I'm working on this item.
I would post rebased fdw_scan patch soon.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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,
--
Shiger
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
> > cost
On Fri, 24 Dec 2010 11:09:16 +0900
Itagaki Takahiro wrote:
> On Tue, Dec 21, 2010 at 21:32, Itagaki Takahiro
> wrote:
> > On Tue, Dec 21, 2010 at 20:14, Shigeru HANADA
> > wrote:
> >> Attached is the revised version of file_fdw patch. This patch is
> >>
statement. You mean that locking remote data through LOCK statement?
It would be better to discuss locking with write-access support.
> 22. Can we build an local index on a foreign table?
No. It would be difficult to determine what we should store abstract
"tuple id", ctid for heap tuple, in index tuples.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;
ERROR: missing data for column "bid"
CONTEXT: COPY csv_tellers_bad, line 10: "10"
postgres=#
* Only superusers can change table-level file_fdw options. Normal
user can't change the options even if the user was the owner of the
table. This is for security re
On Thu, 16 Dec 2010 19:35:56 +0900
Itagaki Takahiro wrote:
> On Thu, Dec 16, 2010 at 18:45, Shigeru HANADA
> wrote:
> > "COPY FROM" is a command which INSERT data from a file essentially,
> > so it requires RowExclusiveLock on the target table. On the other
>
On Tue, 14 Dec 2010 15:51:18 +0900
Itagaki Takahiro wrote:
> On Tue, Dec 14, 2010 at 15:31, Shigeru HANADA
> wrote:
> > In addition to above, ResetCopyFrom() is necessary to support nested
> > loops which inner node is a ForeignScan.
>
> I think you can add ResetCopyFr
ay be better to hide file information if the user was not superuser
for security reason. If so, filename option should not appear in
output of \det psql command too.
Regards,
--
Shigeru Hanada
file_fdw.patch.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
fdw
5) NOT NULL constraint and query-time evaluation
6) column-level FDW option
- syntax and catalog
- column alias option for pgsql_fdw
- force_not_null option for file_fdw
7) RULE
> Copyright notice for new files should go through 2010, not 2009.
Will be fixed in next patch.
oin because ForeignScan is not an
ordered scan, at least in current SQL/MED implementation.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ble foo on the server bar
CREATE FOREIGN TABLE foo SERVER bar;
-- Create zero-column table foo
CREATE FOREIGN TABLE foo () SERVER bar;
To support this feature, another hook function need to be added to FDW
API. ISTM that this feature should be considered with IMPORT SCHEMA
statement.
Regar
LIMIT TO table_list" option.
This syntax would make defining foreign tables easier, but it needs to
enhance both FDW API and core parser.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
de or List.
* FdwExecutionState, a part of ForeignScanState, should be used
instead of ForeignScanState to remove executor details from FDW
implementation.
# ISTM that FdwExecutionState would be replace FdwReply.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Thu, 25 Nov 2010 18:40:09 -0800
David Fetter wrote:
> On Thu, Nov 25, 2010 at 05:51:11PM +0900, Shigeru HANADA wrote:
> > I'm going to add new CommitFest items for this patch and "SQL/MED -
> > postgresql_fdw" patch which have been split from "SQL/MED"
On Thu, 25 Nov 2010 17:12:44 +0900
Shigeru HANADA wrote:
> Attached is a patch that adds file_fdw, FDW which reads records from
> files on the server side, as a contrib module. This patch is based on
> "SQL/MED core functionality" patch.
>
> [SQL/MED - c
though the
contents might not be enough.
Any comments and questions are welcome.
Regards,
--
Shigeru Hanada
pgsql_fdw.patch.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ough.
Any comments and questions are welcome.
Regards,
--
Shigeru Hanada
file_fdw.patch.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, 23 Nov 2010 10:22:02 -0800
"Joshua D. Drake" 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
> > > f
s supported to enable constraint exclusion. In addition, TABLEOID is
supported to show which table is the actual source.
I agree that some kind of documents, such as "How to create new FDW",
should be written.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-ha
tached remove-unused-parameter patch.
Regards,
--
Shigeru Hanada
remove_unused_parameter.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks for the additional information!
On Tue, 16 Nov 2010 09:31:43 -0800
Eric Davies wrote:
> At 01:36 AM 11/16/2010, Shigeru HANADA wrote:
> >On Mon, 15 Nov 2010 08:45:14 -0800
> >Eric Davies wrote:
> >ISTM that index on a VTI table could be inconsistent when original
illion rows.
I couldn't see the way to handle virtual table with more than 4
billion rows with 32 bit rowids in local index. Do you mean that your
"btree-like index" searches result rows by predicates directly and
skips getbyid()?
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
BlockIdData ip_blkid;
OffsetNumber ip_posid;
} ItemPointer;
Does Informix uses common row-id (AFAIK it's 4 bytes integer) for
both of virtual tables and normal tables?
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
On Sat, 6 Nov 2010 16:04:37 +0900
Hitoshi Harada wrote:
> 2010/11/5 Shigeru HANADA :
> > On Fri, 5 Nov 2010 16:27:49 +0900
> > Itagaki Takahiro wrote:
> >> PL/Proxy has a similar functionality with RUN ON ALL to start queries
> >> in parallel. So, I think it
On Fri, 05 Nov 2010 10:43:45 -0400
Tom Lane wrote:
> Shigeru HANADA 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
On Fri, 5 Nov 2010 16:27:49 +0900
Itagaki Takahiro wrote:
> On Fri, Nov 5, 2010 at 4:00 PM, Shigeru HANADA
> wrote:
> >> > * am_beginscan() -> first call of FdwRoutine.Iterate()?
> >> It might be good to have a separated "beginscan" method if we
On Thu, 4 Nov 2010 18:22:52 +0900
Itagaki Takahiro wrote:
> On Thu, Nov 4, 2010 at 6:04 PM, Shigeru HANADA
> wrote:
> > For example:
> > * PRIMARY ACCESS_METHOD -> HANDLER of FOREIGN DATA WRAPPER
> > * am_scancost() -> FdwRoutine
the summary of SQL/MED described in wiki page helps you.
http://wiki.postgresql.org/wiki/SQL/MED
Any comments and questions are welcome.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
make codes complex. Or, we would be able to take the
easiest way, discarding connection at the error.
I'll try to implement cursor-version of postgresql_fdw experimentally
to make this issue clearer.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 13 Oct 2010 19:10:42 -0400
Robert Haas wrote:
> On Tue, Oct 12, 2010 at 2:27 AM, Shigeru HANADA
> wrote:
> > Thanks for the review!
> > I'll finish the SQL/MED patch by applying your comments.
>
> I think this patch has gotten as much review as we
On Mon, 11 Oct 2010 13:22:13 -0400
Robert Haas wrote:
> On Thu, Oct 7, 2010 at 7:20 AM, Shigeru HANADA
> wrote:
> > In this step, optimizer calls FdwRoutine->GetStatistics() to get
> > estimated costs of the foreign scan. ?FDW can calculate costs by
> > itself with so
from API.
== ANALYZE support ==
Even if a FDW wants to keep statistics in local area such as
pg_class.reltuples, current API doesn't provide appropriate timing.
Should we add API which is called from ANALYZE to allow FDWs to handle
statistics when user wants.
Any comments are welcome.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, 4 Oct 2010 19:31:52 -0400
Robert Haas wrote:
> On Thu, Sep 30, 2010 at 3:48 AM, Shigeru HANADA
> wrote:
> > How about having cost hints in generic option of the foreign table or
> > its columns? ?Generic options are storage for wrappers, not for
> > PostgreSQL cor
costs of
a path.
In addition, I think that the generic option of a server could be used
to store cost hints which depend on each server, such as network
transfer overhead for dbms wrappers, or disk I/O for file-wrappers.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ned. Routine mappings can be used to absorb the difference of the
versions.
Any comments are welcome.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
break horribly.
Using remote indexes might be very effective, but I think there are
many issues.
For instance, how can planner/optimizer know whether the foreign table
has been indexed or not? Checking remote catalogs for each scan must
be a bad idea. HiRDB, Hitachi's dbms product, seems to ha
es.
Though all regression tests finish successfully, should this be
fixed ?
regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
r FOREIGN TABLE DDLs and foreign
table query. In the future, the FDW for flat file can be
integrated with COPY FROM.
Any comments/questions are welcome.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
201 - 292 of 292 matches
Mail list logo
