Heikki Linnakangas <hlinnakan...@vmware.com> writes: > On 11/25/2014 05:11 PM, Heikki Linnakangas wrote: >> On 11/24/2014 06:05 PM, Alex Shulgin wrote: >>> Heikki Linnakangas <hlinnakan...@vmware.com> writes: >>>>> >>>>> It appears that replication connection doesn't support URI but only the >>>>> traditional conninfo string. >>>>> >>>>> src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in >>>>> libpqrcv_connect(): >>>>> >>>>> snprintf(conninfo_repl, sizeof(conninfo_repl), >>>>> "%s dbname=replication replication=true >>>>> fallback_application_name=walreceiver", >>>>> conninfo); >>>>> >>>>> A patch to fix this welcome? >>>> >>>> Yeah, seems like an oversight. Hopefully you can fix that without >>>> teaching libpqwalreceiver what connection URIs look like.. >>> >>> Please see attached. We're lucky that PQconnectdbParams has an option >>> to parse and expand the first dbname parameter if it looks like a >>> connection string (or a URI). >>> >>> The first patch is not on topic, I just spotted this missing check. >>> >>> The second one is a self-contained fix, but the third one which is the >>> actual patch depends on the second one, because it specifies the dbname >>> keyword two times: first to parse the conninfo/URI, then to override any >>> dbname provided by the user with "replication" pseudo-database name. >> >> Hmm. Should we backpatch the second patch? It sure seems like an >> oversight rather than deliberate that you can't override dbname from the >> connection string with a later dbname keyword. I'd say "yes". >> >> How about the third patch? Probably not; it was an oversight with the >> connection URI patch that it could not be used in primary_conninfo, but >> it's not a big deal in practice as you can always use a non-URI >> connection string instead. > > Ok, committed the second patch to all stable branches, and the third > patch to master.
It still looks like a bug that primary_conninfo doesn't accept URIs, even though they were supposed to be handled transparently by all interfaces using libpq... Any chance we reconsider and back-patch this up to 9.2? -- Alex -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers