2015-02-21 7:04 GMT+01:00 Pavel Stehule <pavel.steh...@gmail.com>: > Hi > > 2015-02-20 21:55 GMT+01:00 Alvaro Herrera <alvhe...@2ndquadrant.com>: > >> Pavel Stehule wrote: >> > 2015-02-20 8:22 GMT+01:00 David Fetter <da...@fetter.org>: >> > >> > > On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote: >> > > > Hi >> > > > >> > > > I am happy with doc changes now. >> > > > >> > > > When I test last patch, I found sigfault bug, because host = >> > > > PQhost(o_conn); returns NULL. I fexed it - please, see patch 007 >> > > > >> > > > If you are agree with fix, I'll mark this patch as ready for commit. >> > > >> > > Thanks for fixing the bug. Let's go with this. >> > > >> > >> > marked as "ready for commit" >> >> Gave this patch a look. In general it looks pretty good, but there is >> one troublesome point: it duplicates two functions from libpq into psql, >> including the URI designators. This doesn't look very nice. I thought >> about just creating a new src/common (say connstring.c) to host those >> two functions and the URI designators, but then on closer look I noticed >> that libpq's facilities for URI parsing become severed: two very small >> functions become part of libpgcommon, while the more complex parts >> remain in libpq. >> >> On the other hand, if we see that psql needs this functionality, isn't >> this a clue that other client programs might find it useful too? >> (Honestly I'm not completely sure about this point -- other opinions?) >> >> I see three[four] ways forward from here: >> >> 1. export this functionality in libpq as one or two new functions. This >> would need proper docs, exports.txt, etc. >> > > I don't think so it is preferable way - me (as developer) doesn't interest > a format of connection string - and if somebody would to check the format, > then he use a simply regexp. It is task for libpq to check and detect used > format correctly. "psql" works on very low level and needs these > functionality almost all for autocomplete - and it is not usual task for > database based applications. >
and libpq should not bloat too much > > >> >> 2. export it in libpgcommon. If we choose this option we should >> probably rename those functions, as in the attached patch. >> > > +1 > > >> >> 3. accept the patch as is, i.e. duplicate the libq-internal functions in >> psql. >> >> [4. reject the whole thing] >> >> I lean towards (2) myself, but what do others think? >> > > aggree with you > > Regards > > Pavel > > >> >> -- >> Álvaro Herrera http://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >> > >
