be useful to make length of remote transaction same as local's,
I'll try RegisterXactCallback for this purpose, though we need to
preload FDW module to catch BEGIN preceding query using foreign tables.
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
2012/2/2 Marko Kreen mark...@gmail.com:
I think you want this instead:
 https://commitfest.postgresql.org/action/patch_view?id=769
Somehow I've missed this cool feature. Thanks for the suggestion!
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
paranoid concern...
I'll post revised patches 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
PGrowValue.len is less than 0, right?
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
(2012/02/07 23:44), Marko Kreen wrote:
On Tue, Feb 07, 2012 at 07:25:14PM +0900, Shigeru Hanada wrote:
- What is the right (or recommended) way to prevent from throwing
exceptoin in row-processor callback function? When author should use
PG_TRY block to catch exception in the callback
- 6.3x faster than Row Processor
Row processor was almost 2x faster than SQL-cursor! I'm looking forward
to this feature.
In addition to performance gain, of course memory usage was kept at very
low level. :)
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers
(2011/12/15 11:30), Etsuro Fujita wrote:
(2011/12/14 15:34), Shigeru Hanada wrote:
I think this patch could be marked as Ready for committer with some
minor fixes. Please find attached a revised patch (v6.1).
I've tried to make pgsql_fdw work with this feature, and found that few
static
to achieve general semantics mapping for join push-down and WHERE
clause push-down. For 9.2, I'm proposing pgsql_fdw which has WHERE
clause push-down for built-in elements which are free from collation.
I'd like to go back to that item after 9.2 development enters beta or
RC, hopefully :)
--
Shigeru
,
--
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
(2012/02/17 0:15), Albe Laurenz wrote:
Shigeru Hanada wrote:
Thanks for the review. Attached patches are revised version, though
only fdw_helper_v5.patch is unchanged.
Two questions:
- Is it on purpose that you can specify all SSL client options
except sslcompression?
No, just
2012/02/21 0:58 Kevin Grittner kevin.gritt...@wicourts.gov:
Albe Laurenz laurenz.a...@wien.gv.at wrote:
I read the example carefully, and it seems to me that it is
necessary for the read-only transaction (T3)v to be SERIALIZABLE so
that T1 is aborted and the state that T3 saw remains
files? They would contain every
delete/update/drop including cascading ones, though it might be too late
because WAL files are not available until archived.
xlogdump would help reading WAL files.
https://github.com/snaga/xlogdump
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list
is
implemented in backend binary and used by contrib/dblink. I thought
that we should use another name for PostgreSQL FDW unless we can change
specification of dblink connection string.
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
column for foreign tables.
--
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
)
Incidentally, views, which is very similar object type to foreign
tables, have no system columns.
Thoughts?
--
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
should have system columns physically, like the option c).
For now, c) seems most reasonable to me.
--
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
given name
is a valid libpq option would help.
int PQisValidOption(const char *keyword);
--
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
.
--
Shigeru Hanada
diff --git a/contrib/dblink/Makefile b/contrib/dblink/Makefile
index ac63748..a27db88 100644
*** a/contrib/dblink/Makefile
--- b/contrib/dblink/Makefile
*** SHLIB_LINK = $(libpq)
*** 7,13
SHLIB_PREREQS = submake-libpq
EXTENSION = dblink
! DATA = dblink
which doesn't have actual FDW might
confuse users. Rather dblink_validator or libpq_option_validator is better?
One possible another idea is creating dblink_fdw which uses the
validator during CREATE EXTENSION dblink for users who store
connection information in FDW objects.
--
Shigeru Hanada
wouldn't be a serious problem.
Please find attached a patch implementing the design above.
--
Shigeru Hanada
diff --git a/contrib/file_fdw/file_fdw.c b/contrib/file_fdw/file_fdw.c
index 46394a8..bb541e3 100644
*** a/contrib/file_fdw/file_fdw.c
--- b/contrib/file_fdw/file_fdw.c
create_index_path with create_index_paths.
Former creates a IndexScan path node (so it's similar to
create_foreignscan_path), and latter builds multiple IndexScan paths for
a plain relation.
So, just renaming create_foreignscan_path to plural form seems missing
the point.
--
Shigeru Hanada
,
--
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
in document.
--
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
fdw_exprs from baserestrictinfo, with removing clauses
which are pushed down by selected path.
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
into individual
buffers.
Comments to the rest part are in my another reply to your recent post.
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
(2012/03/06 23:47), Albe Laurenz wrote:
Shigeru Hanada wrote:
Connection should be closed only when the trigger is a
top level transaction and it's aborting, but isTopLevel flag was not
checked. I fixed the bug and added regression tests for such cases.
I wondered about
fileIterateForeignScan and
ExecConstraints.
Anyway, please add this patch to Commit Fest App for tracking.
https://commitfest.postgresql.org/action/commitfest_view?id=14
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
other objects with elog(ERROR).
Anyone know the reason?
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
indexed-file_fdw to me...
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, Mar 16, 2012 at 10:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Shigeru HANADA shigeru.han...@gmail.com writes:
During writing pgsql_fdw codes, I noticed that exprCollation rejects
non-Expr nodes with error unrecognized node type: %d. Is this
intentional behavior, or can it return
;
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.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
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
names.
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
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@postgresql.org)
To make changes
On Tue, 14 Dec 2010 15:51:18 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Tue, Dec 14, 2010 at 15:31, Shigeru HANADA han...@metrosystems.co.jp
wrote:
In addition to above, ResetCopyFrom() is necessary to support nested
loops which inner node is a ForeignScan.
I think you
On Thu, 16 Dec 2010 19:35:56 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Thu, Dec 16, 2010 at 18:45, Shigeru HANADA han...@metrosystems.co.jp
wrote:
COPY FROM is a command which INSERT data from a file essentially,
so it requires RowExclusiveLock on the target table
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 reason.
Regards,
--
Shigeru Hanada
file_fdw-20101221
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
On Fri, 24 Dec 2010 11:09:16 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Tue, Dec 21, 2010 at 21:32, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Tue, Dec 21, 2010 at 20:14, Shigeru HANADA han...@metrosystems.co.jp
wrote:
Attached is the revised version
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
it.
Regards,
--
Shigeru Hanada
20101227-psql_dE_doc.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
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
, if any, necessary to execute foreign table
definition are implementation-defined.
/quote
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
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 (pgsql-hackers
/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
On Mon, 10 Jan 2011 19:26:11 -0500
Tom Lane t...@sss.pgh.pa.us wrote:
Shigeru HANADA han...@metrosystems.co.jp 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
On Tue, 11 Jan 2011 13:24:33 +0100
Magnus Hagander mag...@hagander.net 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
(),
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
.
Regards,
--
Shigeru Hanada
20110113-copy_context.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
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
is 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: Binary data
On Fri, 14 Jan 2011 14:20:20 +0900
Shigeru HANADA han...@metrosystems.co.jp wrote:
On Fri, 14 Jan 2011 13:03:27 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
Good catch. I merged your fix into the attached patch.
Thanks, I'll rebase my patches.
I've rebased WIP patches
On Fri, 14 Jan 2011 14:59:00 -0500
Andrew Dunstan and...@dunslane.net 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
at EXECUTE with actual values. With ParamListInfo
parameter for BeginScan(), FDWs would be able to optimize their remote
query with actual parameter values.
Regard,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Mon, 17 Jan 2011 22:13:19 +0900
Shigeru HANADA han...@metrosystems.co.jp 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
if it was EXPLAIN execution.
Regards,
--
Shigeru Hanada
20110118-no_fdw_perm_check.patch.gz
Description: Binary data
20110118-fdw_catalog_lookup.patch.gz
Description: Binary data
20110118-fdw_handler.patch.gz
Description: Binary data
20110118-foreign_scan.patch.gz
Description: Binary data
--
Sent via
On Tue, 18 Jan 2011 15:17:12 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Sat, Jan 15, 2011 at 08:35, Shigeru HANADA han...@metrosystems.co.jp
wrote:
Interface of NextCopyFrom() is fixed to return HeapTuple, to support
tableoid without any change to TupleTableSlot.
3
On Thu, 20 Jan 2011 22:21:37 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Wed, Jan 19, 2011 at 00:34, Shigeru HANADA han...@metrosystems.co.jp
wrote:
Attached patch requires FDW API patches and copy_export-20110114.patch.
Some minor comments:
Thanks for the comments.
I'll
On Fri, 21 Jan 2011 18:28:19 +0200
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
On Mon, 31 Jan 2011 22:00:55 +0900
Shigeru HANADA han...@metrosystems.co.jp 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
are revised 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-hackers
On Mon, 7 Feb 2011 21:00:53 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Mon, Feb 7, 2011 at 16:01, Shigeru HANADA han...@metrosystems.co.jp
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
/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 mailing list (pgsql
On Mon, 07 Feb 2011 09:37:37 +0100
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Tue, 8 Feb 2011 08:49:36 -0500
Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 8, 2011 at 4:42 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
I'll submit revised file_fdw patch after removing IsForeignTable()
catalog lookup along Heikki's proposal.
So I'm a bit confused. I
the one more familiar to me at that time. I think that only few
people feel that postgres is shortened name of
postgresql.
How about using postgres_fdw for PG-FDW?
Regards,
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
cursor to avoid possible memory
exhaust on large result set. I switched to single-row processing mode
(it could be said protocol-level cursor), which was added in 9.2,
because it accomplish same task with less SQL calls than cursor.
Regards,
--
Shigeru HANADA
VERBOSE was
specified. This would make EXPLAIN output easy to read, even if many
foreign tables are used in a query.
Thoughts?
--
Shigeru HANADA
, so 4th number in
the result above should be compared to 4th number of not-patched PG?
--
Shigeru HANADA
drop-in-transaction-v3.1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
.
--
Shigeru HANADA
drop-in-tx.diff
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
about pulling up codes for PGRES_TUPLES_OK case in
StoreQueryResult to new static function, say StoreQueryTuple? It
would make StoreQueryResult more similar to PrintQueryResult's style,
and IMO it makes the code more readable.
Regards,
--
Shigeru HANADA
gset_fix.patch
Description: Binary data
On Tue, Dec 18, 2012 at 2:52 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Attached updated patch
Seems fine. I'll mark this as ready for committer.
Nice work!
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
?
# using RELS instead of RELATIONS would be better to shorten the name
* +1 for Alvaro's suggestion about avoiding palloc traffic by starting
with 8 elements or so.
Regards,
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
elements or so.
Done.
Not yet. Initial size of srels array is still 1 element.
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
call.
OK, both threshold and initial palloc were fixed correctly.
I'll mark this patch as Ready for committer.
Good work! :-)
Regards,
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
, sortConditions() is a misleading function
name. How about categolizeConditions() or screeningConditions()?
How about classifyConditions?
# I hope native English speaker's help for wording issue... :-)
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
. Please refer coding conventions written in
PostgreSQL wiki.
http://www.postgresql.org/docs/devel/static/source-format.html
Once the issues above are fixed, IMO this patch can be marked as Ready
for committer.
Regards,
--
Shigeru Hanada
* 不明 - 自動検出
* 英語
* 日本語
* 英語
* 日本語
(2012/07/12 6:04), Peter Eisentraut wrote:
On tor, 2012-06-14 at 21:29 +0900, Shigeru HANADA wrote:
I'd like to propose pgsql_fdw, FDW for PostgreSQL, as a contrib module
in core, again.
Do you have any new proposals regarding naming, and how to deal with
postgresql_fdw_validator
and leaving it to libpq client library would make
dblink more robust about libpq option changes in future.
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 the
upcoming commit-fest.
Thanks again, I'll try harder this summer. ;-)
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
not read your patch closely yet, but I wonder how we can know
which column is actually updated. If we have only updated image of
tuple, we have to update all remote columns by new values?
--
Shigeru Hanada
pgsql_fdw_93.tar.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing list
seem
to depend on postgresql_fdw_validator deeply.
Comments and questions are welcome.
--
Shigeru HANADA
diff --git a/contrib/dblink/Makefile b/contrib/dblink/Makefile
index ac63748..a27db88 100644
--- a/contrib/dblink/Makefile
+++ b/contrib/dblink/Makefile
@@ -7,7 +7,7 @@ SHLIB_LINK = $(libpq
/pgsql_fdw patch based on this patch.
Thanks for your volunteer :-)
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
for comments above.
Regards,
--
Shigeru HANADA
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index 0e9b408..a76b84d 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -832,7 +832,7 @@ PrintQueryResults(PGresult *results)
*
* Note: Utility function for use by SendQuery
feature else) don't need regression test, we can remove
psql.(sql|out).
# Of course we need to test new feature by hand.
Anyway, IMO the name psql impresses larger area than the patch
implements. How about to rename psql to psql_cmd or backslash_cmd than
psql as regression test name?
--
Shigeru
passed to psql_error end with '¥n',
unless additional information follows. Please see attached patch for
additional change.
After you determine whether it's ok or unnecessary, I'll mark this patch
as Ready for committer.
Regards,
--
Shigeru HANADA
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b
). This would be a bug in
ExecQueryUsingCursor. Please see the last test case in regression test
psql_cmd.
I'll mark this patch as waiting author.
Regards,
--
Shigeru HANADA
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/doc/src/sgml/ref/psql-ref.sgml
***
*** 1483,1490 testdb=gt
DROP TABLEs (not surrounded by BEGIN
and COMMIT) tomorrow to confirm that the patch doesn't introduce
performance degradation.
Regards,
--
Shigeru HANADA
diff --git a/src/backend/catalog/storage.c b/src/backend/catalog/storage.c
index 993bc49..86bca04 100644
--- a/src/backend/catalog/storage.c
+++ b
,
--
Shigeru HANADA
shigeru.han...@gmail.com
be worth mentioning that it's not
recommended to use postgresql_fdw_validator as validator of a
third-party's FDW to avoid dependency.
Regards,
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
, but mentioning it clearly might be better.
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
operator/functions until we support ROUTINE MAPPING
or something like that... Anyway, I'll fix pgsql_fdw to allow = and !=
for character types.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
# make core first for libpq et al.
$ cd contrib/pgsql_fdw
$ make # pgsql_fdw
Please try git clean and make clean, if you have not.
FWIW, I'm using GNU Make 3.82 and gcc 4.6.0 on Fedora 15.
Regards,
--
Shigeru HANADA
--
Sent via pgsql-hackers
,
still we would be able to create plans on the basis of default
selectivity for each expression, as same as regular tables.
Regards,
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
in current
CF, so I'd like to push it.
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
,
--
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
measured in
months at most, and I don't want to have to try to fix every FDW when
it changes. But I think we can easily revise the hook details to fix
that, and I'm hoping to get that done today.
I'll try implementing the design you suggested.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers
On Sat, Apr 7, 2012 at 4:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Shigeru HANADA shigeru.han...@gmail.com writes:
Just after my post, Fujita-san posted another v7 patch[1], so I merged
v7 patches into v8 patch.
I've committed a modified version of this, but right after pushing it
I had
to administrator command
FATAL: terminating connection due to administrator command
This seems to impress users that remote side has some trouble.
Regards,
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
1 - 100 of 289 matches
Mail list logo
