From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Karl O(dot) Pinc <kop(at)meme(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql, remove include of psqlscan.c |
Date: | 2012-09-27 15:41:35 |
Message-ID: | 1348760000-sup-4477@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Karl O. Pinc's message of jue sep 27 12:29:53 -0300 2012:
> The reason I want this is because I don't want to have to
> rewrite the sql parser in PHP for inclusion in phpPgAdmin.
> (I did this once, and it was such a big ugly patch
> it never got around to getting into the mainline phpPgAdmin.)
> phpPgAdmin (pgAdmin/ front-end of your choice)
> should be able process a string of sql statements in the
> same way that psql does, but currently the only way to
> do this is to rewrite the parser in each application.
> Much better to have libpq provide the functionality,
> although I suppose it's possible to push this into the
> server.
This seems a worthy goal to me.
But I think I see what Tom objection to it is: if we "export" this
capability to libpq applications, then we set it in stone to a certain
extent: exactly how things are split would become part of the API, so to
speak. Upgrading to a newer libpq could break application code that
worked with the previous release's by splitting things differently.
I don't currently have an opinion on whether this is a bad thing or not.
Who wants to argue for/against?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | John R Pierce | 2012-09-27 15:48:38 | Re: psql, remove include of psqlscan.c |
Previous Message | Karl O. Pinc | 2012-09-27 15:29:53 | Re: psql, remove include of psqlscan.c |