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

2009/3/11 Simon Riggs <simon(at)2ndquadrant(dot)com>:
>
> 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.

No, now I want to add hook only to current parser - concretely to
transformations, although I can imagine any hook over whole parser. It
could help with modules, that adds non sql statements like "show
statistic", "show ... ", "explain " and others - all service
statements, some extensions ... Nearest goal is support for some smart
functions like decode, greatest, xmlelement, ...

>
> 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.
>

I can test debug_query_string, but main problem is impossibility throw
exception inside PG_init.

regards
Pavel Stehule

> --
>  Simon Riggs           www.2ndQuadrant.com
>  PostgreSQL Training, Services and Support
>
>