Re: Parser extensions (maybe for 10?)

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: José Luis Tallón <jltallon(at)adv-solutions(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parser extensions (maybe for 10?)
Date: 2016-04-13 14:43:33
Message-ID: CAMsr+YGSQJ=nG_QXxhtVQqWD=1awQ2+DqyD0CmKxk5qzE6X+Rg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 13 April 2016 at 22:11, José Luis Tallón <jltallon(at)adv-solutions(dot)net>
wrote:

> FWIW, I have previously sketched a "syntax rewriter" of sorts: a simple
> filter which is applied to input before the lexer even sees it.
> Quite some "syntax magic" can be achieved by allowing an extension to
> *hook* into this functionality in order to do some rewriting; If turning
> one statement into several (multi-statement) is also allowed quite some
> serious emulation could be achieved.
>

Some DBMSes have hooks that let you match statements to patterns and/or by
hash and replace them with a wholly different statement. It seems to be a
feature to work around applications that've fossilized completely, with
source code long lost or binaries provided by a vendor who went out of
business years ago. Or cranked their prices for the new version. Or, of
course, where the apps team have built a fort with spiked pits, a
portcullis, and a molten lead trap between their office and the DBA team's
office, where the DBA team crouch behind desks covered in woad clutching
their swords and knives. Treaty negotiations have entirely fallen through
and they throw rocks instead of talking to each other.

The idea is that in such delightful situations where you can't/won't fix
terrible queries in the application you instead match them in the DBMS and
transparently rewrite them.

I hear "but we can't change the application" often enough to understand why
such hooks exist, but not often enough to particularly want them in
PostgreSQL.

I can certainly prepare a small patch for the first commitfest of 9.7 if
> this sounds viable.
>

I'd be surprised if it was popular. It's hard to imagine a way to do it
robustly when dealing with pre-lexer input, unless you're doing simple
pattern matching to identify and replace whole statements.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-04-13 15:01:16 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Previous Message Tom Lane 2016-04-13 14:42:03 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <