2009/3/11 Simon Riggs <si...@2ndquadrant.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 > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
