Re: Precedence of standard comparison operators - Mailing list pgsql-hackers

On 2015-02-26 20:13:34 +0000, Simon Riggs wrote:
> 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.

I can see a point in having the ability to plug in a parser - I just
don't think it has much to do with this topic. It'd be a nightmare to
maintain two versions of our parser; I don't think anybody wants to
patch more than one.

> Whole planner replacement is used for extensions by CitusData and NTT,
> and will definitely be used in the future for other apps.

s/planner/parser/? Because replacing the planner can already be done as
a whole without much problems.

> Whole executor replacement is also used by one extension to produce
> DDL triggers.

Hm?

> 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.

Assuming you meant parser: Maybe. I have my doubt somebody will actually
invest the significant amount of time to develop something like
that. But I don't have a problem providing the capability; there seems
little point in allowing to replace the optimizer but not the planner. I
just don't see that it has much to do with this discussion.

Greetings,

Andres Freund

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