Re: regress bug - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: regress bug
Date
Msg-id 41E47A9E-9924-416E-80BE-80AB4B4BA1A0@justatheory.com
Whole thread Raw
In response to Re: regress bug  (Andrew Dunstan <andrew.dunstan@pgexperts.com>)
Responses Re: regress bug  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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).
Butfile_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
ina subdirectory. My extensions have the .sql files in an sql/ directory. So that means when I have something like this
insql/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
justdo 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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: regress bug
Next
From: "Kevin Grittner"
Date:
Subject: t_natts references in comments