Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME
Дата
Msg-id 4E959270.3040803@dunslane.net
обсуждение исходный текст
Ответ на Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers

On 10/12/2011 04:39 AM, Heikki Linnakangas wrote:
> On 12.10.2011 10:58, Stefan Kaltenbrunner wrote:
>> On 10/12/2011 09:53 AM, Martin Pitt wrote:
>>> Hello all,
>>>
>>> In https://launchpad.net/bugs/835502 it was reported that the 9.1.1
>>> contrib *.sql files contain the token "MODULE_PATHNAME", which is
>>> unknown:
>>>
>>>    psql test<  /usr/share/postgresql/9.1/extension/intarray--1.0.sql
>>>
>>> This fails with a ton of errors about the file "MODULE_PATHNAME" not
>>> existing.
>>>
>>> When I replace this with "$libdir/_int", it works:
>>>
>>>    sed 's!MODULE_PATHNAME!$libdir/_int!g' 
>>> /usr/share/postgresql/9.1/extension/intarray--1.0.sql | psql test
>>>
>>> Is that something I'm doing wrong in the packaging, or should the
>>> contrib Makefiles be fixed to do this substitution?
>>>
>>> It doesn't only affect intarray, but pretty much all *.sql files.
>>
>> uh - the reason is that contrib is now packaged as extensions and that
>> you are supposed to use "CREATE EXTENSION intarray;" on the SQL level
>> instead of manually loading sql-scripts through psql.
>
> 9.1 has been out for only a couple of months, and we've seen a lot of 
> people trying to do that already. In hindsight, we probably should've 
> chosen a different filename extension for those files, to make it 
> clear that you can't just run them in psql. It's too late for that, 
> but a comment at the top of the .sql files would be good:
>
>

I've made this mistake myself in an unthinking moment. I suggest that we 
deprecate calling them something.sql and add code ASAP providing for 
some other suffix ( .xtn ?) with legacy support for falling back to 
.sql. I'd almost be inclined to backpatch it while there are so few 
third party extensions out there.

cheers

andrew




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.2] DROP statement reworks
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Overhead cost of Serializable Snapshot Isolation