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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: idea, proposal: only preloadable libraries (conditional load)
Date: 2009-03-11 12:56:11
Message-ID: 1236776171.28644.118.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.com
PostgreSQL Training, Services and Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-03-11 12:57:42 Re: Has anybody think about changing BLCKSZ to an option of initdb?
Previous Message Tom Lane 2009-03-11 12:42:41 Re: gcc: why optimize for size flag is not the default