Re: Parser extensions (maybe for 10?) - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: Parser extensions (maybe for 10?)
Date
Msg-id 20160418182523.3f70ad88@fujitsu
Whole thread Raw
In response to Re: Parser extensions (maybe for 10?)  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Parser extensions (maybe for 10?)
List pgsql-hackers
> I cannot to imagine extensible parser based on bison. But the parser
> can be replaced by custom parser.
> 
> Some like pgpool or pgbouncer does. The extension can assign own
> parser. Custom parser will be called first, and the integrated parser
> will be used from extension or as fallback. This can helps with new
> statements for background workers, theoretically it can helps with
> extending PostgreSQL SQL. Custom parser can do translation from SQL1
> to SQL2 dialect, or can do translation from SQL1 to internal calls.
> The custom parser usually should not implement full SQL - only few
> statements.
> 
> Is it this idea more workable?

What if there are two or more contribs that extend the parser? Can we
be sure that these contribs will not conflict?

-- 
Best regards,
Aleksander Alekseev
http://eax.me/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Spinlocks and semaphores in 9.2 and 9.3
Next
From: Andres Freund
Date:
Subject: Re: Spinlocks and semaphores in 9.2 and 9.3