On 26 February 2015 at 15:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think the way to do this is to have a pluggable parser, so users can
>> choose 1) old parser, 2) new, better parser, 3) any other parser they
>> fancy that they maintain to ensure application compatibility. We've
>> got a pluggable executor and optimizer, so why not a parser too?
>> Implementing that in the same way we have done for executor and
>> optimizer is a 1 day patch, so easily achievable for 9.5.
>
> I don't find that particularly attractive either. It seems quite unlikely
> to me that anyone would actually use such a hook; replacing the whole
> parser would be essentially unmaintainable. Nobody uses the hooks you
> mention to replace the whole planner or whole executor --- there are
> wrappers out there, which is a different thing altogether. But you could
> not undo the issue at hand here without at the very least a whole new
> copy of gram.y, which would need to be updated constantly if you wanted
> it to keep working across more than one release.
That's not what I see.
Whole planner replacement is used for extensions by CitusData and NTT,
and will definitely be used in the future for other apps.
Whole executor replacement is also used by one extension to produce
DDL triggers.
In any case, whole planner replacement would be very desirable for
people trying to minimize code churn in their applications. As soon as
it exists, I will use to make some MySQL-only apps work seamlessly
against PostgreSQL, such as WordPress. It doesn't need to be 100%
perfect MySQL, it just needs to be enough to make the app work.
Maintaining a code base that can work against multiple databases is
hard. Writing it against one main database and maintaining a parser
layer would be much easier.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, RemoteDBA, Training &
Services