Re: POLA violation with \c service= - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: POLA violation with \c service=
Date
Msg-id CAFj8pRAQvYSyd2S4mtGDzviSa4UkwGV10aTa89QAfdE6goXzCQ@mail.gmail.com
Whole thread Raw
In response to Re: POLA violation with \c service=  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: POLA violation with \c service=  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Hi

2015-02-20 21:55 GMT+01:00 Alvaro Herrera <alvherre@2ndquadrant.com>:
Pavel Stehule wrote:
> 2015-02-20 8:22 GMT+01:00 David Fetter <david@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.
 

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

pgsql-hackers by date:

Previous
From: Gavin Flower
Date:
Subject: Re: Abbreviated keys for Numeric
Next
From: Pavel Stehule
Date:
Subject: Re: POLA violation with \c service=