On 04.02.2013 17:32, Alvaro Herrera wrote:
Phil Sorber wrote:
On Mon, Feb 4, 2013 at 10:16 AM, Alvaro Herrera
<alvhe...@2ndquadrant.com> wrote:
Phil Sorber wrote:
On Mon, Feb 4, 2013 at 9:13 AM, Alvaro Herrera<alvhe...@2ndquadrant.com> wrote:
Uh, no existing code can use this new functionality? That seems
disappointing.
I wrote this because I wanted to use it in pg_isready. I also wrote
something for pg_isready to get around not having this. I think adding
these two functions to libpq would be the better option, but wanted
something that could fix an existing issue without having to patch
libpq so late in the 9.3 development process. Actually, I think it was
you who suggested that approach.
Yes, I realize that (and yes, I did). But is no code other than
pg_isready doing this? Not even the libpq URI test program?
I think it probably would be able to benefit from this. Are you
suggesting I patch that too? I thought it was usually frowned upon to
touch random bits of working code like that. I'd be more than happy to
do it if it helps build the case for getting this added.
Well, this qualifies as refactoring, so yeah, it helps the case.
I think this patch would simplift the patch to pass a connection string
to pg_basebackup and pg_receivexlog:
http://www.postgresql.org/message-id/005501cdfa45$6b0eec80$412cc580$@ko...@huawei.com.
I note that pg_dumpall also has a similar issue as pg_basebackup and
pg_receivexlog; there's no way to pass a connection string to it either.
If you could come up with a unified patch that takes care of all of
those, that would be great.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
