Thread: [GENERAL] Connection options
Hi, ALL, I'm looking at the documentation at www.postgresql.org/docs/current/static/libpq-connect.html section 32.1.2. The part for "option" reads: [quote] Specifies command-line options to send to the server... [/quote] Does this mean that if I'm writing a C/C++ program, I shouldn't care about that? Or there are legitimate set of options I can set to pass to PQconnectDB()? Thank you.
Hi, again, On Thu, Jun 15, 2017 at 2:59 PM, Igor Korot <ikorot01@gmail.com> wrote: > Hi, ALL, > I'm looking at the documentation at > www.postgresql.org/docs/current/static/libpq-connect.html > section 32.1.2. > > The part for "option" reads: > > [quote] > Specifies command-line options to send to the server... > [/quote] > > Does this mean that if I'm writing a C/C++ program, I shouldn't care about that? > Or there are legitimate set of options I can set to pass to PQconnectDB()? In addition: Where can I get a list of client encoding I can pass on the connection to the server? Thank you. > > Thank you.
On 06/15/2017 12:02 PM, Igor Korot wrote: > Hi, again, > > On Thu, Jun 15, 2017 at 2:59 PM, Igor Korot <ikorot01@gmail.com> wrote: >> Hi, ALL, >> I'm looking at the documentation at >> www.postgresql.org/docs/current/static/libpq-connect.html >> section 32.1.2. >> >> The part for "option" reads: >> >> [quote] >> Specifies command-line options to send to the server... >> [/quote] >> >> Does this mean that if I'm writing a C/C++ program, I shouldn't care about that? >> Or there are legitimate set of options I can set to pass to PQconnectDB()? > > In addition: > > Where can I get a list of client encoding I can pass on the connection > to the server? https://www.postgresql.org/docs/9.6/static/multibyte.html > > Thank you. > >> >> Thank you. > > -- Adrian Klaver adrian.klaver@aklaver.com
Hi, Adrian, On Thu, Jun 15, 2017 at 4:13 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > On 06/15/2017 12:02 PM, Igor Korot wrote: >> >> Hi, again, >> >> On Thu, Jun 15, 2017 at 2:59 PM, Igor Korot <ikorot01@gmail.com> wrote: >>> >>> Hi, ALL, >>> I'm looking at the documentation at >>> www.postgresql.org/docs/current/static/libpq-connect.html >>> section 32.1.2. >>> >>> The part for "option" reads: >>> >>> [quote] >>> Specifies command-line options to send to the server... >>> [/quote] >>> >>> Does this mean that if I'm writing a C/C++ program, I shouldn't care >>> about that? >>> Or there are legitimate set of options I can set to pass to >>> PQconnectDB()? >> >> >> In addition: >> >> Where can I get a list of client encoding I can pass on the connection >> to the server? > > > https://www.postgresql.org/docs/9.6/static/multibyte.html Is it possible to update the libpq-connect page with this link? And could you clarify on the first part of this? From the quote I poste it sounds like this is available only in command-line tools. And if someone will use it inside the program it will be ignored. Thank you. > >> >> Thank you. >> >>> >>> Thank you. >> >> >> > > > -- > Adrian Klaver > adrian.klaver@aklaver.com
On 06/15/2017 01:23 PM, Igor Korot wrote: > Hi, Adrian, > > On Thu, Jun 15, 2017 at 4:13 PM, Adrian Klaver > <adrian.klaver@aklaver.com> wrote: >> On 06/15/2017 12:02 PM, Igor Korot wrote: >>> >>> Hi, again, >>> >>> On Thu, Jun 15, 2017 at 2:59 PM, Igor Korot <ikorot01@gmail.com> wrote: >>>> >>>> Hi, ALL, >>>> I'm looking at the documentation at >>>> www.postgresql.org/docs/current/static/libpq-connect.html >>>> section 32.1.2. >>>> >>>> The part for "option" reads: >>>> >>>> [quote] >>>> Specifies command-line options to send to the server... >>>> [/quote] >>>> >>>> Does this mean that if I'm writing a C/C++ program, I shouldn't care >>>> about that? >>>> Or there are legitimate set of options I can set to pass to >>>> PQconnectDB()? >>> >>> >>> In addition: >>> >>> Where can I get a list of client encoding I can pass on the connection >>> to the server? >> >> >> https://www.postgresql.org/docs/9.6/static/multibyte.html > > Is it possible to update the libpq-connect page with this link? Probably something you could bring up on: https://www.postgresql.org/list/pgsql-docs/ > > And could you clarify on the first part of this? >From the quote I poste it sounds like this is available only in command-line > tools. And if someone will use it inside the program it will be ignored. I use tools that use libpq, but I do not use it directly so I do not have a definitive answer. I do see this: "Several libpq functions parse a user-specified string to obtain connection parameters. There are two accepted formats for these strings: plain keyword = value strings and RFC 3986 URIs." at the head of the section(32.1.1. Connection Strings) from which you quoted. What those functions are I have no idea. > > Thank you. > >> >>> >>> Thank you. >>> >>>> >>>> Thank you. >>> >>> >>> >> >> >> -- >> Adrian Klaver >> adrian.klaver@aklaver.com > -- Adrian Klaver adrian.klaver@aklaver.com
And could you clarify on the first part of this?
From the quote I poste it sounds like this is available only in command-line
tools. And if someone will use it inside the program it will be ignored.
The options you pass from the client via the "options" attribute are interpreted by *the server* as command-line options. They are not options that control libpq itself.
I can kinda see the confusion here but I'm not sure how to write it more clearly without being excessively verbose. I haven't seen this particular confusion before so I'd say the wording is reasonable and the mailing lists are doing their job of providing a forum for providing clarity.
David J.
Hi, David,
On Thu, Jun 15, 2017 at 4:46 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Thu, Jun 15, 2017 at 1:23 PM, Igor Korot <ikorot01@gmail.com> wrote:
>>
>> And could you clarify on the first part of this?
>> From the quote I poste it sounds like this is available only in
>> command-line
>> tools. And if someone will use it inside the program it will be ignored.
>
>
> The options you pass from the client via the "options" attribute are
> interpreted by *the server* as command-line options. They are not options
> that control libpq itself.
Can you give an example or try to explain it?
What do you mean by "interpreted by the server as command-line options"?
Does this mean I can just ignore this parameter inside my C{++} program?
Or I can set some options and pass it to the server thru this parameter?
>
> I can kinda see the confusion here but I'm not sure how to write it more
> clearly without being excessively verbose. I haven't seen this particular
> confusion before so I'd say the wording is reasonable and the mailing lists
> are doing their job of providing a forum for providing clarity.
Well for someone who is just started with PostgreSQL and C interface it is
confusing.
Thank you.
>
> David J.
>
On 06/15/2017 02:41 PM, Igor Korot wrote:
> Hi, David,
>
> On Thu, Jun 15, 2017 at 4:46 PM, David G. Johnston
> <david.g.johnston@gmail.com> wrote:
>> On Thu, Jun 15, 2017 at 1:23 PM, Igor Korot <ikorot01@gmail.com> wrote:
>>>
>>> And could you clarify on the first part of this?
>>> From the quote I poste it sounds like this is available only in
>>> command-line
>>> tools. And if someone will use it inside the program it will be ignored.
>>
>>
>> The options you pass from the client via the "options" attribute are
>> interpreted by *the server* as command-line options. They are not options
>> that control libpq itself.
>
> Can you give an example or try to explain it?
> What do you mean by "interpreted by the server as command-line options"?
>
> Does this mean I can just ignore this parameter inside my C{++} program?
> Or I can set some options and pass it to the server thru this parameter?
>
>>
>> I can kinda see the confusion here but I'm not sure how to write it more
>> clearly without being excessively verbose. I haven't seen this particular
>> confusion before so I'd say the wording is reasonable and the mailing lists
>> are doing their job of providing a forum for providing clarity.
>
> Well for someone who is just started with PostgreSQL and C interface it is
> confusing.
Maybe this will help:
https://www.postgresql.org/docs/9.6/static/libpq-example.html
>
> Thank you.
>
>>
>> David J.
>>
--
Adrian Klaver
adrian.klaver@aklaver.com
On Thu, Jun 15, 2017 at 4:46 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Thu, Jun 15, 2017 at 1:23 PM, Igor Korot <ikorot01@gmail.com> wrote:
>>
>> And could you clarify on the first part of this?
>> From the quote I poste it sounds like this is available only in
>> command-line
>> tools. And if someone will use it inside the program it will be ignored.
>
>
> The options you pass from the client via the "options" attribute are
> interpreted by *the server* as command-line options. They are not options
> that control libpq itself.
Can you give an example or try to explain it?
What do you mean by "interpreted by the server as command-line options"?
Does this mean I can just ignore this parameter inside my C{++} program?
Or I can set some options and pass it to the server thru this parameter?
Reading this should help:
Note especially 19.1.4 - Parameter Interaction via the Shell
For example:
postgres -c 'search_path=app,public'
is roughly equivalent to:
psql "options='-c search_path=app,public'"
which can written directly in libpq as (not a C programmer here so I'm going for pseudo code):
keyarray=[options]
valarray=["-c search_path=app,public"]
PQconnectdbParams(keyarray, valarray, 0)
Equivalent in that the session that ends up being started will already have a search_path value of "app,public" (it does depend on where else search_path defaults are setup).
Note that you can get much the same behavior by doing:
$ psql
> SET search_path TO app, public;
In fact, if your are routing your connections through pg_bouncer making use of "options" (-c search_path=app,public) won't work and you'll want to either use "SET search_path TO app, public" or possibly one of the "ALTER DATABASE/ ALTER USER" commands to setup your connection defaults.
In short, you can choose to forgo using session startup options which are passed to the server and treated by it as command-line (shell) options. I suspect most users do.
32.1.2 lists all of the words that can appear in the "keyarray" above - these configure the client so it can talk to the server. If the word chosen is "options", however, the valid values come from what the server recognizes and instructs the server to start the newly connected session with the GUC/configuration variables set to the specified values.
David J.
Igor Korot <ikorot01@gmail.com> writes: > On Thu, Jun 15, 2017 at 4:46 PM, David G. Johnston > <david.g.johnston@gmail.com> wrote: >> The options you pass from the client via the "options" attribute are >> interpreted by *the server* as command-line options. They are not options >> that control libpq itself. > Can you give an example or try to explain it? > What do you mean by "interpreted by the server as command-line options"? See the switches described in https://www.postgresql.org/docs/current/static/app-postgres.html The point of the libpq "options" argument is that you can pass server settings using that same switch syntax, for settings you'd be allowed to change at runtime. This is obsolete legacy stuff; all of the available options can be set with SET commands, and that's the preferred way to do it now. regards, tom lane
Igor Korot <ikorot01@gmail.com> writes:
> On Thu, Jun 15, 2017 at 4:46 PM, David G. Johnston
> <david.g.johnston@gmail.com> wrote:
>> The options you pass from the client via the "options" attribute are
>> interpreted by *the server* as command-line options. They are not options
>> that control libpq itself.
> Can you give an example or try to explain it?
> What do you mean by "interpreted by the server as command-line options"?
See the switches described in
https://www.postgresql.org/docs/current/static/app- postgres.html
The point of the libpq "options" argument is that you can pass server
settings using that same switch syntax, for settings you'd be allowed to
change at runtime. This is obsolete legacy stuff; all of the available
options can be set with SET commands, and that's the preferred way to do
it now.
Centralization of client-side logic in self-contained scripts is a thing I try to do. The recent changes to psql -c/-f in 9.6 seem to now provide me a viable alternative to passing the desired startup search_path via options. Prior to 9.6 using a custom PSQLRC and restricting myself to -f and stdin would get me close; but -c ignoring (without the ability to override) the PSQLRC sourcing made it imperfect.
I didn't learn that pg_bouncer shared this belief (out of necessity) until later though. And while I'm inclined to agree I'd suggest we actually make such a declaration formal so people reading the docs and considering adding such an argument to their custom psql aliases can instead decide to use something different. I'm not sure if I'd bleep a deprecation warning from psql though - if so, adding a silencer switch would be courteous.
David J.