Re: idea, proposal: only preloadable libraries (conditional load) - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: idea, proposal: only preloadable libraries (conditional load)
Date
Msg-id 1236776171.28644.118.camel@ebony.2ndQuadrant
Whole thread Raw
In response to idea, proposal: only preloadable libraries (conditional load)  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: idea, proposal: only preloadable libraries (conditional load)
Re: idea, proposal: only preloadable libraries (conditional load)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: gcc: why optimize for size flag is not the default
Next
From: Greg Stark
Date:
Subject: Re: Has anybody think about changing BLCKSZ to an option of initdb?