Re: idea, proposal: only preloadable libraries (conditional load)

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: idea, proposal: only preloadable libraries (conditional load)
Дата
Msg-id 1236776171.28644.118.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на idea, proposal: only preloadable libraries (conditional load)  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: idea, proposal: only preloadable libraries (conditional load)
Re: idea, proposal: only preloadable libraries (conditional load)
Список pgsql-hackers
On Wed, 2009-03-11 at 11:09 +0100, Pavel Stehule wrote:

> I am searching way to extensible parser (actually not bison, only
> transformations). I propose parserHook (transformation part). One
> Tom's objection is difference between heooked and unhooked parser. It
> serious problem.

Do you mean hooking the whole parser? That sounds more useful and less
hassle than trying to hook parts of it. That would be just one check to
see if the hook exists per statement, rather than potentially thousands
of times per statement.

I'd go for an implementation that uses pg_language to store new
languages, just with lanispl = false. We can then have a new parameter
session_language (TEXT) with 'internal' as default. session_language
cannot be reset while connected. That would allow us to have multiple
session languages in use at one time and to add new ones (or modify
existing ones) without changing core behaviour.

In the longer term it will be very useful to have the ability to support
multiple language variants, including older PostgreSQL syntax to allow
legacy systems to work with Postgres at the same time as allowing new
development to continue.

> I have one idea - only preloadable libraries. These libs have to be
> specified in local_preload_libraries variable, and cannot be
> initialised by LOAD statement. Statement LOAD should by used only for
> reload library. Because pre loaded library is initialised before first
> SQL statement should be executed, then hook is installed on time and
> an behave is consistent. One technique is an calling library's
> function "canload" before initialising. When canload returns false,
> then dfmgr unloads lib. I thing so this behave complements current
> functions PG_init and PG_finit. What I can understand, PG_init, cannot
> throw exception or signalise any problems with initialisation.

I remember I had some differences between the way loading occurs at
session start and as a result of a LOAD command. I think there's
probably already a way of doing this - probably by checking for
something that would only be there *after* having read reloadable
libraries but before main session starts.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: gcc: why optimize for size flag is not the default
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Has anybody think about changing BLCKSZ to an option of initdb?