Re: Replication connection URI?

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:

> On 11/25/2014 05:11 PM, Heikki Linnakangas wrote:
>> On 11/24/2014 06:05 PM, Alex Shulgin wrote:
>>> Heikki Linnakangas <hlinnakangas(at)vmware(dot)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