From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: regress bug |
Date: | 2012-03-08 20:26:06 |
Message-ID: | 41E47A9E-9924-416E-80BE-80AB4B4BA1A0@justatheory.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mar 8, 2012, at 12:20 PM, Andrew Dunstan wrote:
> It works fine if you don't need to do any file conversions (i.e. if you don't have "input" or "output" directories). But file_textarray_fdw does.
>
> Here's a patch that I think fixes the problem.
While you’re there, an issue I noticed is that the MODULE_PATHNAME substitutions do not work if you have your SQL files in a subdirectory. My extensions have the .sql files in an sql/ directory. So that means when I have something like this in sql/plproxy.sql.in:
CREATE FUNCTION plproxy_call_handler ()
RETURNS language_handler AS 'MODULE_PATHNAME' LANGUAGE C;
What I end up with in sql/plproxy.sql is:
CREATE FUNCTION plproxy_call_handler ()
RETURNS language_handler AS 'sql/plproxy' LANGUAGE C;
Which doesn’t work at all, because the file is not installed in an `sql` subdirectory, it's just that way in my repository (and the distribution tarball). So I avoid the whole MODULE_PATHNAME business for now (and the .in file) and just do this, instead:
CREATE FUNCTION plproxy_call_handler ()
RETURNS language_handler AS 'plproxy' LANGUAGE C;
Which is an okay workaround, but I’m not sure that MODULE_PATHNAME is actually working correctly.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-03-08 20:33:29 | t_natts references in comments |
Previous Message | Andrew Dunstan | 2012-03-08 20:20:59 | Re: regress bug |