Skip site navigation (1) Skip section navigation (2)

Re: Notes on implementing URI syntax for libpq

From: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
To: Alexander Shulgin <ash(at)commandprompt(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Notes on implementing URI syntax for libpq
Date: 2011-11-24 07:41:08
Message-ID: CAAfz9KM-vqLu5q5pUN2Xh2XEBnCpzostGV_Mf1EKxSrW9BrXqw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2011/11/24 Alexander Shulgin <ash(at)commandprompt(dot)com>

>
> Excerpts from Dmitriy Igrishin's message of Thu Nov 24 09:19:02 +0200 2011:
> >
> > > If host part of the URI points to localhost, the UNIX domain socket
> would
> > > be considered by libpq just as if you would pass "-h localhost -p
> 5433".
> > >
> > But what if the user wants to connect exactly via socket or
> > TCP/IP ?
> > And what if the user needs to specify a socket file name extension?
>
> How do you achieve that with the current psql set of command line options
> (and, possibly environment variables?)
>
For psql(1) see -h option and -p option
http://www.postgresql.org/docs/9.1/static/app-psql.html
For the libpq see host option and port option of PQconnectdbparams()
http://www.postgresql.org/docs/9.1/static/libpq-connect.html
In both cases:
If the value of host begins with a slash, it is used as the directory for
the Unix-domain socket.
Port specifies the TCP port or the local Unix-domain socket file extension.

>
> I would think the same method will work with URI, as with the proposed
> approach the URI is just decomposed into host, port and dbname parts and
> the rest of the code works like if you've had specified "-h example.net-p 5433 -d mydb" instead of the URI parameter.
>
Thats great, but see above.



-- 
// Dmitriy.

In response to

pgsql-hackers by date

Next:From: Jan UrbaƄskiDate: 2011-11-24 08:07:02
Subject: Re: PL/Python SQL error code pass-through
Previous:From: Martijn van OosterhoutDate: 2011-11-24 07:40:42
Subject: Re: Notes on implementing URI syntax for libpq

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group