Re: psql, remove include of psqlscan.c
От | Alvaro Herrera |
---|---|
Тема | Re: psql, remove include of psqlscan.c |
Дата | |
Msg-id | 1348760000-sup-4477@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: psql, remove include of psqlscan.c ("Karl O. Pinc" <kop@meme.com>) |
Ответы |
Re: psql, remove include of psqlscan.c
Re: psql, remove include of psqlscan.c |
Список | 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
В списке pgsql-hackers по дате отправления: