Connection options

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.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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.

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.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Thu, Jun 15, 2017 at 2:41 PM, Igor Korot <ikorot01@gmail.com> wrote:

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:

​https://www.postgresql.org/docs/current/static/config-setting.html

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Thu, Jun 15, 2017 at 3:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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.