pg_receivexlog always handles -d option argument as connstr
Hi all,
pg_receivexlog always handles argument of -d option as connstr formatted value.
We can doubly specify host name, port number.
The other client tools handles -d option as connstr value only if
argument has "=" character.
The document says that pg_receivexlog ignores database name, and this
option is called for consistency with other client applications.
But if we specify database name like other client tool '-d hoge' ,
then we will definitely got error.
I think that pg_receivexlog should be changed to get consistency with
other client tools.
Thought?
Regards,
-------
Sawada Masahiko
--
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, Oct 6, 2014 at 10:23 PM, Sawada Masahiko <sawada.mshk@gmail.com>
wrote:
Hi all,
pg_receivexlog always handles argument of -d option as connstr formatted
value.
We can doubly specify host name, port number.
The other client tools handles -d option as connstr value only if
argument has "=" character.
pg_basebackup also seems to behave same as pg_receivexlog.
psql also treats it in similar way. The behaviour of psql is as
below:
psql.exe -d="host=localhost port=5432 dbname=postgres"
psql: invalid connection option ""
psql.exe -d "host=localhost port=5432 dbname=postgres"
psql (9.5devel)
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.
postgres=#
The document says that pg_receivexlog ignores database name, and this
option is called for consistency with other client applications.
But if we specify database name like other client tool '-d hoge' ,
then we will definitely got error.
What I understand from document is that it ignores database name
when given in connection string.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Tue, Oct 7, 2014 at 12:58 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Mon, Oct 6, 2014 at 10:23 PM, Sawada Masahiko <sawada.mshk@gmail.com>
wrote:Hi all,
pg_receivexlog always handles argument of -d option as connstr formatted
value.
We can doubly specify host name, port number.
The other client tools handles -d option as connstr value only if
argument has "=" character.pg_basebackup also seems to behave same as pg_receivexlog.
psql also treats it in similar way. The behaviour of psql is as
below:
psql.exe -d="host=localhost port=5432 dbname=postgres"
psql: invalid connection option ""psql.exe -d "host=localhost port=5432 dbname=postgres"
psql (9.5devel)
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.postgres=#
The document says that pg_receivexlog ignores database name, and this
option is called for consistency with other client applications.
But if we specify database name like other client tool '-d hoge' ,
then we will definitely got error.What I understand from document is that it ignores database name
when given in connection string.
Yep, but we can use -d option like 'psql -d postgres'.
pg_receivexlog and pg_basebackup doesn't seem to work like that.
they always handles argument as connstr formatted value.
psql handles argument as database name or connstr, depends on variable argument.
$ bin/pg_receivexlog -D xlog_dir/ -S hoge -d postgres -p 5432
pg_receivexlog: missing "=" after "postgres" in connection info string
Regards,
-------
Sawada Masahiko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 7, 2014 at 8:13 PM, Sawada Masahiko <sawada.mshk@gmail.com>
wrote:
On Tue, Oct 7, 2014 at 12:58 PM, Amit Kapila <amit.kapila16@gmail.com>
wrote:
On Mon, Oct 6, 2014 at 10:23 PM, Sawada Masahiko <sawada.mshk@gmail.com>
wrote:Hi all,
pg_receivexlog always handles argument of -d option as connstr
formatted
value.
We can doubly specify host name, port number.
The other client tools handles -d option as connstr value only if
argument has "=" character.pg_basebackup also seems to behave same as pg_receivexlog.
psql also treats it in similar way. The behaviour of psql is as
below:
psql.exe -d="host=localhost port=5432 dbname=postgres"
psql: invalid connection option ""psql.exe -d "host=localhost port=5432 dbname=postgres"
psql (9.5devel)
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.postgres=#
The document says that pg_receivexlog ignores database name, and this
option is called for consistency with other client applications.
But if we specify database name like other client tool '-d hoge' ,
then we will definitely got error.What I understand from document is that it ignores database name
when given in connection string.Yep, but we can use -d option like 'psql -d postgres'.
pg_receivexlog and pg_basebackup doesn't seem to work like that.
they always handles argument as connstr formatted value.
psql needs to connect to particular database for its functioning where
as pg_basebackup/pg_receivexlog works differently and doesn't
need to connect to particular database for its functioning, so I am not
sure why you want them to behave similarly for -d switch.
Moreover the same is clarified in docs, so whats the issue?
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Amit Kapila<amit.kapila16@gmail.com>
On Tue, Oct 7, 2014 at 8:13 PM, Sawada Masahiko <sawada.mshk@gmail.com
<javascript:_e(%7B%7D,'cvml','sawada.mshk@gmail.com');>> wrote:On Tue, Oct 7, 2014 at 12:58 PM, Amit Kapila <amit.kapila16@gmail.com
<javascript:_e(%7B%7D,'cvml','amit.kapila16@gmail.com');>> wrote:
On Mon, Oct 6, 2014 at 10:23 PM, Sawada Masahiko <
sawada.mshk@gmail.com
<javascript:_e(%7B%7D,'cvml','sawada.mshk@gmail.com');>>wrote:
Hi all,
pg_receivexlog always handles argument of -d option as connstr
formatted
value.
We can doubly specify host name, port number.
The other client tools handles -d option as connstr value only if
argument has "=" character.pg_basebackup also seems to behave same as pg_receivexlog.
psql also treats it in similar way. The behaviour of psql is as
below:
psql.exe -d="host=localhost port=5432 dbname=postgres"
psql: invalid connection option ""psql.exe -d "host=localhost port=5432 dbname=postgres"
psql (9.5devel)
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.postgres=#
The document says that pg_receivexlog ignores database name, and this
option is called for consistency with other client applications.
But if we specify database name like other client tool '-d hoge' ,
then we will definitely got error.What I understand from document is that it ignores database name
when given in connection string.Yep, but we can use -d option like 'psql -d postgres'.
pg_receivexlog and pg_basebackup doesn't seem to work like that.
they always handles argument as connstr formatted value.psql needs to connect to particular database for its functioning where
as pg_basebackup/pg_receivexlog works differently and doesn't
need to connect to particular database for its functioning, so I am not
sure why you want them to behave similarly for -d switch.
Moreover the same is clarified in docs, so whats the issue?
Yes, I got your point.
I thought that it's a little confusion that,
Although the document says -d option of pg_receivexlog is called for
consistency,
Behavior of psql(other tool) and pg_receivexlog aren't exactly same.
If user use same -d option like '-d hoge_db' on both tool pg_receivexlog and
psql for easir setting, then it leads to occur error on pg_receivexlog side.
I thought pg_receivexlog should ignore database name even thought -d option
value is not connsrr formatted value, same as psql dose.
But there may be not any such case.
Regards,
Sawada Masahiko
--
Regards,
-------
Sawada Masahiko