Extend file_fdw wrapper
Attached patch.
------------
pasman
Attachments:
0001-Extend-file_fdw-wrapper.patchapplication/octet-stream; name=0001-Extend-file_fdw-wrapper.patchDownload
From 397fd464b63a47689004a88e6c83e024521b789a Mon Sep 17 00:00:00 2001
From: pasman <pasman.p@gmail.com>
Date: Mon, 10 Oct 2011 08:21:58 +0200
Subject: [PATCH] Extend file_fdw wrapper. Allows to add options to foreign
server: encoding, format, header, delimiter, escape, quote,
null.
---
contrib/file_fdw/file_fdw.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/contrib/file_fdw/file_fdw.c b/contrib/file_fdw/file_fdw.c
index 4eb87e6..acb043e 100644
--- a/contrib/file_fdw/file_fdw.c
+++ b/contrib/file_fdw/file_fdw.c
@@ -17,6 +17,7 @@
#include "access/reloptions.h"
#include "catalog/pg_foreign_table.h"
+#include "catalog/pg_foreign_server.h"
#include "commands/copy.h"
#include "commands/defrem.h"
#include "commands/explain.h"
@@ -44,6 +45,16 @@ struct FileFdwOption
* fileGetOptions(), which currently doesn't bother to look at user mappings.
*/
static struct FileFdwOption valid_options[] = {
+
+ /*Server options*/
+ {"format", ForeignServerRelationId},
+ {"header", ForeignServerRelationId},
+ {"delimiter", ForeignServerRelationId},
+ {"quote", ForeignServerRelationId},
+ {"escape", ForeignServerRelationId},
+ {"null", ForeignServerRelationId},
+ {"encoding", ForeignServerRelationId},
+
/* File options */
{"filename", ForeignTableRelationId},
--
1.7.6.msysgit.0
2011/10/10 pasman pasmański <pasman.p@gmail.com>:
Attached patch.
... and what are these new options intended to do?
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
and a foreign server?
Also I think documents and regression tests would be required for
this kind of change.
Regards,
--
Shigeru Hanada
On Mon, Oct 10, 2011 at 10:51:03PM +0900, Shigeru Hanada wrote:
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
and a foreign server?
I believe that the finer-grained setting should always override the
coarser, so in this case, the setting for the table should take
precedence over the setting for the server.
Also I think documents and regression tests would be required for
this kind of change.
+1 :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On 10/10/2011 09:51 AM, Shigeru Hanada wrote:
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
and a foreign server?Also I think documents and regression tests would be required for
this kind of change.
I'm not even sure I understand why we should want this anyway. The
closest analog I can think of to a more conventional server is that the
whole file system is the foreign server, and there just don't seem to be
any relevant options at that level. All the options being supplied seem
much saner left as just foreign table options.
cheers
andrew
Hi.
Current behaviour is error message when foreign table and foreign
server have the same option defined.
I don't know how to write regression test, may i read about it somewhere?
--
------------
pasman
Import Notes
Resolved by subject fallback
On Mon, Oct 10, 2011 at 10:23:51AM -0400, Andrew Dunstan wrote:
On 10/10/2011 09:51 AM, Shigeru Hanada wrote:
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
and a foreign server?Also I think documents and regression tests would be required for
this kind of change.I'm not even sure I understand why we should want this anyway. The
closest analog I can think of to a more conventional server is that
the whole file system is the foreign server, and there just don't
seem to be any relevant options at that level. All the options being
supplied seem much saner left as just foreign table options.
You raise an excellent point, which is that there probably should be
options at that level which override the (settable) generic file_fdw
options.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On 10/10/2011 11:59 AM, David Fetter wrote:
On Mon, Oct 10, 2011 at 10:23:51AM -0400, Andrew Dunstan wrote:
On 10/10/2011 09:51 AM, Shigeru Hanada wrote:
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
and a foreign server?Also I think documents and regression tests would be required for
this kind of change.I'm not even sure I understand why we should want this anyway. The
closest analog I can think of to a more conventional server is that
the whole file system is the foreign server, and there just don't
seem to be any relevant options at that level. All the options being
supplied seem much saner left as just foreign table options.You raise an excellent point, which is that there probably should be
options at that level which override the (settable) generic file_fdw
options.
That's not my point at all.
cheers
andrew