POLA violation with \c service=

I do indeed see this behavior in some very quick testing using 9.3

David Fetter wrote

I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.

Looking at the docs the fact it attempts to treat "service=foo" as anything
other than a database name is broken...

I can think of a few approaches for fixing this:

0. Leave it broken.
1. Disable "service=" requests entirely in \c context, and error out if
attempted.
2. Ensure that \c actually uses all of the available information.

Is there another one I missed?

If not, which of the approaches seems reasonable?

#2 has a few possible final implementations to consider given that both \c
and service= can be incompletely specified and what happens if both \c-host
and service-host, for instance, are specified...but I'm not in a position to
reason out the various possibilities right now. Regardless, the ability to
specify a service name is valuable (if one presumes \c is valuable) so the
tasks are finding an implementer and, depending on that outcome, how to
handle back-branches.

I don't think the status-quo is safe enough to leave so for head either #1
or #2 get my vote. Leaving it broken in back branches is not appealing but
maybe we can selectively break it if we cannot get a #2 implementation that
can be back-patched.

An aside - from the docs: "If there is no previous connection [...]" - how
is this possible when issuing \c?

David J.

--
View this message in context: http://postgresql.nabble.com/POLA-violation-with-c-service-tp5831001p5831026.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

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

David Fetter wrote:

I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.

This came up in the context of connecting to a cloud hosting service
named after warriors or a river or something, whose default hostnames
are long, confusing, and easy to typo, so I suspect that service= may
come up more often going forward than it has until now.

For example, when I try to use

\c "service=foo"

It will correctly figure out which database I'm trying to connect to,
but fail to notice that it's on a different host, port, etc., and
hence fail to connect with a somewhat unhelpful error message.

I can think of a few approaches for fixing this:

0. Leave it broken.
1. Disable "service=" requests entirely in \c context, and error out if attempted.
2. Ensure that \c actually uses all of the available information.

Is there another one I missed?

If not, which of the approaches seems reasonable?

#2 is the correct solution, #1 a band aid.

Yours,
Laurenz Albe

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

On 12/17/2014 10:03 AM, Albe Laurenz wrote:

David Fetter wrote:

I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.

This came up in the context of connecting to a cloud hosting service
named after warriors or a river or something, whose default hostnames
are long, confusing, and easy to typo, so I suspect that service= may
come up more often going forward than it has until now.

For example, when I try to use

\c "service=foo"

It will correctly figure out which database I'm trying to connect to,
but fail to notice that it's on a different host, port, etc., and
hence fail to connect with a somewhat unhelpful error message.

I can think of a few approaches for fixing this:

0. Leave it broken.
1. Disable "service=" requests entirely in \c context, and error out if attempted.
2. Ensure that \c actually uses all of the available information.

Is there another one I missed?

If not, which of the approaches seems reasonable?

#2 is the correct solution, #1 a band aid.

It would be handy, if \c "service=foo" actually worked. We should do #3.
If the database name is actually a connection string, or a service
specification, it should not re-use the hostname and port from previous
connection, but use the values from the connection string or service file.

- Heikki

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

On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:

On 12/17/2014 10:03 AM, Albe Laurenz wrote:

David Fetter wrote:

I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.

This came up in the context of connecting to a cloud hosting service
named after warriors or a river or something, whose default hostnames
are long, confusing, and easy to typo, so I suspect that service= may
come up more often going forward than it has until now.

For example, when I try to use

\c "service=foo"

It will correctly figure out which database I'm trying to connect to,
but fail to notice that it's on a different host, port, etc., and
hence fail to connect with a somewhat unhelpful error message.

I can think of a few approaches for fixing this:

0. Leave it broken.
1. Disable "service=" requests entirely in \c context, and error
out if attempted.
2. Ensure that \c actually uses all of the available information.

Is there another one I missed?

If not, which of the approaches seems reasonable?

#2 is the correct solution, #1 a band aid.

It would be handy, if \c "service=foo" actually worked. We should do
#3. If the database name is actually a connection string, or a service
specification, it should not re-use the hostname and port from
previous connection, but use the values from the connection string or
service file.

Yeah, that's the correct solution. It should not be terribly difficult
to create a test for a conninfo string in the dbname parameter. That's
what libpq does after all. We certainly don't want psql to have to try
to interpret the service file. psql just needs to let libpq do its work
in this situation.

cheers

andrew

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

On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:

On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:

On 12/17/2014 10:03 AM, Albe Laurenz wrote:

David Fetter wrote:

I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.

This came up in the context of connecting to a cloud hosting service
named after warriors or a river or something, whose default hostnames
are long, confusing, and easy to typo, so I suspect that service= may
come up more often going forward than it has until now.

For example, when I try to use

\c "service=foo"

It will correctly figure out which database I'm trying to connect to,
but fail to notice that it's on a different host, port, etc., and
hence fail to connect with a somewhat unhelpful error message.

I can think of a few approaches for fixing this:

0. Leave it broken.
1. Disable "service=" requests entirely in \c context, and error out
if attempted.
2. Ensure that \c actually uses all of the available information.

Is there another one I missed?

If not, which of the approaches seems reasonable?

#2 is the correct solution, #1 a band aid.

It would be handy, if \c "service=foo" actually worked. We should do #3.
If the database name is actually a connection string, or a service
specification, it should not re-use the hostname and port from previous
connection, but use the values from the connection string or service file.

Yeah, that's the correct solution. It should not be terribly difficult to
create a test for a conninfo string in the dbname parameter. That's what
libpq does after all. We certainly don't want psql to have to try to
interpret the service file. psql just needs to let libpq do its work in this
situation.

letting libpq handle this is the only sane plan for fixing it. I'm
looking into that today.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

On Wed, Dec 17, 2014 at 8:25 AM, David Fetter [via PostgreSQL] <
ml-node+s1045698n5831124h68@n5.nabble.com> wrote:

On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:

On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:

On 12/17/2014 10:03 AM, Albe Laurenz wrote:

David Fetter wrote:

I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.

This came up in the context of connecting to a cloud hosting service
named after warriors or a river or something, whose default hostnames
are long, confusing, and easy to typo, so I suspect that service= may
come up more often going forward than it has until now.

For example, when I try to use

\c "service=foo"

It will correctly figure out which database I'm trying to connect to,
but fail to notice that it's on a different host, port, etc., and
hence fail to connect with a somewhat unhelpful error message.

I can think of a few approaches for fixing this:

0. Leave it broken.
1. Disable "service=" requests entirely in \c context, and error out
if attempted.
2. Ensure that \c actually uses all of the available information.

Is there another one I missed?

If not, which of the approaches seems reasonable?

#2 is the correct solution, #1 a band aid.

It would be handy, if \c "service=foo" actually worked. We should do

#3.

If the database name is actually a connection string, or a service
specification, it should not re-use the hostname and port from previous
connection, but use the values from the connection string or service

file.

Yeah, that's the correct solution. It should not be terribly difficult

to

create a test for a conninfo string in the dbname parameter. That's what
libpq does after all. We certainly don't want psql to have to try to
interpret the service file. psql just needs to let libpq do its work in

this

situation.

letting libpq handle this is the only sane plan for fixing it. I'm
looking into that today.

​
​On a tangentially related note; it is not outside the realm of possibility
that a user would want one pg_service entry​

​to reference another one​:

[realentry]
user=
dbname=

[aliasentry]
service=realentry

furthermore, having a shareable entry like:

[main-host]
host=ip-address
port=5433

[main-user1]
user=user1
service=main-host

[main-user2]
​user=user2
service=main-host

also seems potentially useful.

I just sent a -doc report that nothing in the documentation says this
behavior is not implemented but a cursory attempt at it confirms the lack.

While you are digging in there anything fundamental prohibiting the
behavior and is it something you ​think would be useful in these complex
environments you are working with?

David J.

Sorry about the oddball CC: but I don't have an e-mail with a full set of
recipients...
​

--
View this message in context: http://postgresql.nabble.com/POLA-violation-with-c-service-tp5831001p5831538.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

On Fri, Dec 19, 2014 at 07:03:36PM -0700, David Johnston wrote:

On Wed, Dec 17, 2014 at 8:25 AM, David Fetter [via PostgreSQL] <
ml-node+s1045698n5831124h68@n5.nabble.com> wrote:

On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:

On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:

On 12/17/2014 10:03 AM, Albe Laurenz wrote:

David Fetter wrote:

I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.

This came up in the context of connecting to a cloud hosting service
named after warriors or a river or something, whose default hostnames
are long, confusing, and easy to typo, so I suspect that service= may
come up more often going forward than it has until now.

For example, when I try to use

\c "service=foo"

It will correctly figure out which database I'm trying to connect to,
but fail to notice that it's on a different host, port, etc., and
hence fail to connect with a somewhat unhelpful error message.

I can think of a few approaches for fixing this:

0. Leave it broken.
1. Disable "service=" requests entirely in \c context, and error out
if attempted.
2. Ensure that \c actually uses all of the available information.

Is there another one I missed?

If not, which of the approaches seems reasonable?

#2 is the correct solution, #1 a band aid.

It would be handy, if \c "service=foo" actually worked. We should do

#3.

If the database name is actually a connection string, or a service
specification, it should not re-use the hostname and port from previous
connection, but use the values from the connection string or service

file.

Yeah, that's the correct solution. It should not be terribly difficult

to

create a test for a conninfo string in the dbname parameter. That's what
libpq does after all. We certainly don't want psql to have to try to
interpret the service file. psql just needs to let libpq do its work in

this

situation.

letting libpq handle this is the only sane plan for fixing it. I'm
looking into that today.

​
​On a tangentially related note; it is not outside the realm of possibility
that a user would want one pg_service entry​

​to reference another one​:

You want entries in the service system to be able reference other
entries, setting defaults, for example? Interesting idea. As you
say, it's tangential to this.

The bug I found, and I'm increasingly convinced it's a bug whose fix
should be back-patched, is that psql fails to let libpq do its job
with the extant service system, or more precisely prevents it from
doing only part of its job, leading to broken behavior.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:

On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:

On 12/17/2014 10:03 AM, Albe Laurenz wrote:

David Fetter wrote:

I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.

This came up in the context of connecting to a cloud hosting service
named after warriors or a river or something, whose default hostnames
are long, confusing, and easy to typo, so I suspect that service= may
come up more often going forward than it has until now.

For example, when I try to use

\c "service=foo"

It will correctly figure out which database I'm trying to connect to,
but fail to notice that it's on a different host, port, etc., and
hence fail to connect with a somewhat unhelpful error message.

I can think of a few approaches for fixing this:

0. Leave it broken.
1. Disable "service=" requests entirely in \c context, and error out
if attempted.
2. Ensure that \c actually uses all of the available information.

Is there another one I missed?

If not, which of the approaches seems reasonable?

#2 is the correct solution, #1 a band aid.

It would be handy, if \c "service=foo" actually worked. We should do #3.
If the database name is actually a connection string, or a service
specification, it should not re-use the hostname and port from previous
connection, but use the values from the connection string or service file.

Yeah, that's the correct solution. It should not be terribly difficult to
create a test for a conninfo string in the dbname parameter. That's what
libpq does after all. We certainly don't want psql to have to try to
interpret the service file. psql just needs to let libpq do its work in this
situation.

This took a little longer to get time to polish than I'd hoped, but
please find attached a patch which:

- Correctly connects to service= and postgres(ql)?:// with \c
- Disallows tab completion in the above cases

I'd like to see about having tab completion actually work correctly in
at least the service= case, but that's a matter for a follow-on patch.

Thanks to Andrew Dunstan for the original patch, and to Andrew Gierth
for his help getting it into shape.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Tue, Dec 30, 2014 at 04:48:11PM -0800, David Fetter wrote:

On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:

Yeah, that's the correct solution. It should not be terribly difficult to
create a test for a conninfo string in the dbname parameter. That's what
libpq does after all. We certainly don't want psql to have to try to
interpret the service file. psql just needs to let libpq do its work in this
situation.

This took a little longer to get time to polish than I'd hoped, but
please find attached a patch which:

- Correctly connects to service= and postgres(ql)?:// with \c
- Disallows tab completion in the above cases

I'd like to see about having tab completion actually work correctly in
at least the service= case, but that's a matter for a follow-on patch.

Thanks to Andrew Dunstan for the original patch, and to Andrew Gierth
for his help getting it into shape.

Cheers,
David.

I should mention that the patch also corrects a problem where the
password was being saved/discarded at inappropriate times. Please
push this patch to the back branches :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

On Mon, Jan 05, 2015 at 02:26:59PM -0800, David Fetter wrote:

On Tue, Dec 30, 2014 at 04:48:11PM -0800, David Fetter wrote:

On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:

Yeah, that's the correct solution. It should not be terribly difficult to
create a test for a conninfo string in the dbname parameter. That's what
libpq does after all. We certainly don't want psql to have to try to
interpret the service file. psql just needs to let libpq do its work in this
situation.

This took a little longer to get time to polish than I'd hoped, but
please find attached a patch which:

- Correctly connects to service= and postgres(ql)?:// with \c
- Disallows tab completion in the above cases

I'd like to see about having tab completion actually work correctly in
at least the service= case, but that's a matter for a follow-on patch.

Thanks to Andrew Dunstan for the original patch, and to Andrew Gierth
for his help getting it into shape.

Cheers,
David.

I should mention that the patch also corrects a problem where the
password was being saved/discarded at inappropriate times. Please
push this patch to the back branches :)

Per discussion with Stephen Frost, I've documented the previously
undocumented behavior with conninfo strings and URIs.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Thu, Jan 08, 2015 at 08:04:47PM -0800, David Fetter wrote:

On Mon, Jan 05, 2015 at 02:26:59PM -0800, David Fetter wrote:

On Tue, Dec 30, 2014 at 04:48:11PM -0800, David Fetter wrote:

On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:

Yeah, that's the correct solution. It should not be terribly difficult to
create a test for a conninfo string in the dbname parameter. That's what
libpq does after all. We certainly don't want psql to have to try to
interpret the service file. psql just needs to let libpq do its work in this
situation.

This took a little longer to get time to polish than I'd hoped, but
please find attached a patch which:

- Correctly connects to service= and postgres(ql)?:// with \c
- Disallows tab completion in the above cases

I'd like to see about having tab completion actually work correctly in
at least the service= case, but that's a matter for a follow-on patch.

Thanks to Andrew Dunstan for the original patch, and to Andrew Gierth
for his help getting it into shape.

Cheers,
David.

I should mention that the patch also corrects a problem where the
password was being saved/discarded at inappropriate times. Please
push this patch to the back branches :)

Per discussion with Stephen Frost, I've documented the previously
undocumented behavior with conninfo strings and URIs.

Some C cleanups...

I think longer term we should see about having libpq export the
functions I've put in common.[ch], but that's for a later patch.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Fri, January 9, 2015 20:15, David Fetter wrote:

[psql_fix_uri_service_003.patch]

Applies on master; the feature (switching services) works well but a \c without any parameters produces a segfault:

(centos 6.6, 4.9.2, 64-bit)

$ echo -en "$PGSERVICEFILE\n$PGSERVICE\n$PGPORT\n"
/home/aardvark/.pg_service
service_pola
6968

$ psql
Timing is on.
psql (9.5devel_service_pola_20150109_2340_ac7009abd228)
Type "help" for help.

testdb=# \c service=HEAD
You are now connected to database "testdb" as user "aardvark" via socket in "/tmp" at port "6545".
testdb=# \c service=service_pola
You are now connected to database "testdb" as user "aardvark" via socket in "/tmp" at port "6968".
testdb=# \c
Segmentation fault (core dumped)

or, under gdb:

(gdb) run
Starting program: /home/aardvark/pg_stuff/pg_installations/pgsql.service_pola/bin/psql
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Timing is on.
psql (9.5devel_service_pola_20150109_2340_ac7009abd228)
Type "help" for help.

testdb=# \c

Program received signal SIGSEGV, Segmentation fault.
0x000000000040b1f5 in uri_prefix_length (connstr=0x0) at common.c:1785
1785 if (strncmp(connstr, uri_designator,
(gdb) bt
#0 0x000000000040b1f5 in uri_prefix_length (connstr=0x0) at common.c:1785
#1 recognized_connection_string (connstr=connstr@entry=0x0) at common.c:1805
#2 0x0000000000406592 in do_connect (port=0x676960 "6968", host=0x676940 "/tmp", user=0x676900 "aardvark", dbname=0x0) at
command.c:1643
#3 exec_command (query_buf=0x678150, scan_state=0x677fc0, cmd=0x68f730 "c") at command.c:247
#4 HandleSlashCmds (scan_state=scan_state@entry=0x677fc0, query_buf=0x678150) at command.c:112
#5 0x0000000000411283 in MainLoop (source=0x32d4b8e6c0 <_IO_2_1_stdin_>) at mainloop.c:335
#6 0x0000000000413b4e in main (argc=<optimized out>, argv=0x7fffffffd9f8) at startup.c:340
(gdb)

I hope that helps to pinpoint the problem.

thanks,

Erik Rijkers

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

On 01/09/2015 02:15 PM, David Fetter wrote:

Some C cleanups...

Not quite enough cleanup. As I told you on IRC, the only addition to
common.h should be the declaration of recognized_connection_string.
These do not belong there (they belong in common.c):

    +static const char uri_designator[] = "postgresql://";
    +static const char short_uri_designator[] = "postgres://";

These declarations in common.h would cause a separate instance of these
pieces of storage to occur in every object file where the .h file had
been #included. In general, you should not expect to see any static
declarations in .h files.

In addition, you need to ensure that recognized_connection_string() is
not called with a NULL argument.

cheers

andrew

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

On 2015-01-10 09:16:07 -0500, Andrew Dunstan wrote:

+static const char uri_designator[] = "postgresql://";
+static const char short_uri_designator[] = "postgres://";

These declarations in common.h would cause a separate instance of these
pieces of storage to occur in every object file where the .h file had been
#included. In general, you should not expect to see any static declarations
in .h files.

Save static inline functions, that is.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

On 01/10/2015 09:32 AM, Andres Freund wrote:

On 2015-01-10 09:16:07 -0500, Andrew Dunstan wrote:

+static const char uri_designator[] = "postgresql://";
+static const char short_uri_designator[] = "postgres://";

These declarations in common.h would cause a separate instance of these
pieces of storage to occur in every object file where the .h file had been
#included. In general, you should not expect to see any static declarations
in .h files.

Save static inline functions, that is.

Yeah, but not normally data items. (I did say "in general"). As a
general rule for novice C programmers I think my rule of thumb is
reasonable.

cheers

andrew

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

On 2015-01-10 09:49:52 -0500, Andrew Dunstan wrote:

Save static inline functions, that is.

Yeah, but not normally data items. (I did say "in general"). As a general
rule for novice C programmers I think my rule of thumb is reasonable.

Agreed. I just tried to preempt somebody grepping for static in
src/include and crying foul ;)

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

On Sat, Jan 10, 2015 at 09:30:57AM +0100, Erik Rijkers wrote:

On Fri, January 9, 2015 20:15, David Fetter wrote:

[psql_fix_uri_service_003.patch]

Applies on master; the feature (switching services) works well but a \c without any parameters produces a segfault:

(centos 6.6, 4.9.2, 64-bit)

$ echo -en "$PGSERVICEFILE\n$PGSERVICE\n$PGPORT\n"
/home/aardvark/.pg_service
service_pola
6968

$ psql
Timing is on.
psql (9.5devel_service_pola_20150109_2340_ac7009abd228)
Type "help" for help.

testdb=# \c service=HEAD
You are now connected to database "testdb" as user "aardvark" via socket in "/tmp" at port "6545".
testdb=# \c service=service_pola
You are now connected to database "testdb" as user "aardvark" via socket in "/tmp" at port "6968".
testdb=# \c
Segmentation fault (core dumped)

Fixed by running that function only if the argument exists.

More C cleanups, too.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Sat, Jan 10, 2015 at 04:41:16PM -0800, David Fetter wrote:

On Sat, Jan 10, 2015 at 09:30:57AM +0100, Erik Rijkers wrote:

On Fri, January 9, 2015 20:15, David Fetter wrote:

[psql_fix_uri_service_003.patch]

Applies on master; the feature (switching services) works well but a \c without any parameters produces a segfault:

(centos 6.6, 4.9.2, 64-bit)

$ echo -en "$PGSERVICEFILE\n$PGSERVICE\n$PGPORT\n"
/home/aardvark/.pg_service
service_pola
6968

$ psql
Timing is on.
psql (9.5devel_service_pola_20150109_2340_ac7009abd228)
Type "help" for help.

testdb=# \c service=HEAD
You are now connected to database "testdb" as user "aardvark" via socket in "/tmp" at port "6545".
testdb=# \c service=service_pola
You are now connected to database "testdb" as user "aardvark" via socket in "/tmp" at port "6968".
testdb=# \c
Segmentation fault (core dumped)

Fixed by running that function only if the argument exists.

More C cleanups, too.

Added to the upcoming commitfest.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

Hi all

I am sending a review of this patch:

* What it does? - Allow to connect to other db by \connect uri connection
format

postgres=# \c postgresql://localhost?service=old
psql (9.5devel, server 9.2.9)
You are now connected to database "postgres" as user "pavel".

* Would we this feature? - yes, it eliminate inconsistency between cmd line
connect and \connect. It is good idea without any objections.

* This patch is cleanly applicable, later compilation without any issues

* All regress tests passed

* A psql documentation is updated -- this feature (and format) is not
widely known, so maybe some more examples are welcome

* When I tested this feature, it worked as expected

* Code respects PostgreSQL coding rules. I prefer a little bit different
test if keep password. Current code is little bit harder to understand. But
I can live with David's code well too.

if
(!user)

user = PQuser(o_conn);

if
(!host)

host =
PQhost(o_conn);

if
(!port)

port =
PQport(o_conn);

if
(dbname)

has_connection_string =
recognized_connection_string(dbname);

/* we should not to keep password if some connection property is changed
*/

keep_password = strcmp(user, PQuser(o_conn)) == 0 && strcmp(host,
PQhost(o_conn)) == 0
&& strcmp(port, PQport(o_conn)) == 0 &&
!has_connection_string;

I have not any other comments.

Possible questions:
1. more examples in doc
2. small change how to check keep_password

Regards

Pavel

2015-01-13 15:00 GMT+01:00 David Fetter <david@fetter.org>: