Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER nameHANDLER ...
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER nameHANDLER ... |
Дата | |
Msg-id | 2a7349fc-1b23-7fc6-f2bc-bff20688429b@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER nameHANDLER ... (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER nameHANDLER ...
|
Список | pgsql-hackers |
On 2017/09/13 16:42, Ashutosh Bapat wrote: > On Wed, Sep 13, 2017 at 7:49 AM, Amit Langote wrote: >> In the attached updated patch, I created separate .source files in >> src/test/regress/input and output directories called fdw_handler.source >> and put the test_fdw_handler function definition there. When I had >> originally thought of it back when I wrote the patch, it seemed to be an >> overkill, because we're just normally defining a single C function there >> to be used in the newly added foreign_data tests. In any case, we need to >> go the .source file way, because that's the only way to refer to paths to >> .so library when defining C language functions. > > It still looks like an overkill to add a new file to define a dummy > FDW handler. Why do we need to define a handler as a C function? Can't > we define handler as a SQL function. If we could do that we could add > the function definition in foreign_data.sql itself. I guess that's because the last time I tried to define the handler as a SQL function, I couldn't: create function test_fdw_handler() returns fdw_handler as '' language sql; ERROR: SQL functions cannot return type fdw_handler fdw_handler is a pseudo-type, which neither SQL nor plpgsql function can return. Am I missing something? Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: