Re: [PATCHES] psql patch
Tom Lane a ecrit le 13/09/2006 18:05: Guillaume Lelarge <[EMAIL PROTECTED]> writes: diff -r1.89 print.c 853c853
Re: [PATCHES] psql patch
Guillaume Lelarge <[EMAIL PROTECTED]> writes:
> diff -r1.89 print.c
> 853c853
> < snprintf(record_str, 64, "* Record
> %lu", record++);
> ---
>> snprintf(record_str, 64, _("* Record %lu"), record++);
> 855c855
> < snprintf(record_str, 64, "[ RECORD %lu
> ]", record++);
> ---
>> snprintf(record_str, 64, _("[ RECORD %lu ]"), record++);
Hm, these strings were never localizable in previous versions; if we
make them so, do we risk breaking any code that examines psql output?
What about the equivalent headers in the other output formats?
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] psql patch: new host/port without leaving session
Neil Conway wrote: > On Sun, 2006-04-02 at 12:37 -0400, Tom Lane wrote: > > That seems like a frammish without sufficient use-case. You can always > > quit and restart psql to get back to the defaults. > > Patch applied to HEAD. > > If folks want to argue for the ability to instruct psql to use the libpq > default for a parameter, I'm not fundamentally opposed, but that change > can be made subsequently. I think what is applied is enough. That +/- syntax was too confusing to be useful. -- Bruce Momjian http://candle.pha.pa.us + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] psql patch: new host/port without leaving session
On Sun, 2006-04-02 at 12:37 -0400, Tom Lane wrote: > That seems like a frammish without sufficient use-case. You can always > quit and restart psql to get back to the defaults. Patch applied to HEAD. If folks want to argue for the ability to instruct psql to use the libpq default for a parameter, I'm not fundamentally opposed, but that change can be made subsequently. -Neil ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] psql patch: new host/port without leaving session
On Apr 02 12:37, Tom Lane wrote: > Volkan YAZICI <[EMAIL PROTECTED]> writes: > > Won't it be better if we distinguish between "default" and "current" > > value of a parameter with '-' (for the "current") and '+' (for the > > "default") characters? For example: > > That seems like a frammish without sufficient use-case. You can always > quit and restart psql to get back to the defaults. You can always quit and restart psql with new connection parameters. In this situation, we shouldn't bother with \c too. Don't they share the same use-case? (If there's any.) Regards. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] psql patch: new host/port without leaving session
Volkan YAZICI <[EMAIL PROTECTED]> writes: > On Apr 01 07:07, Neil Conway wrote: >> One question about behavior: in the attached patch, omitting an argument >> to \connect or specifying "-" are treated equivalently -- the value for >> that parameter from the previous connection is used, otherwise NULL (for >> the libpq default). Is this what people want? (One possible complaint is >> that once you specify a parameter, you can't get back to the libpq >> default without specifying it explicitly.) > Won't it be better if we distinguish between "default" and "current" > value of a parameter with '-' (for the "current") and '+' (for the > "default") characters? For example: That seems like a frammish without sufficient use-case. You can always quit and restart psql to get back to the defaults. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] psql patch: new host/port without leaving session
On Apr 01 07:07, Neil Conway wrote: > One question about behavior: in the attached patch, omitting an argument > to \connect or specifying "-" are treated equivalently -- the value for > that parameter from the previous connection is used, otherwise NULL (for > the libpq default). Is this what people want? (One possible complaint is > that once you specify a parameter, you can't get back to the libpq > default without specifying it explicitly.) Won't it be better if we distinguish between "default" and "current" value of a parameter with '-' (for the "current") and '+' (for the "default") characters? For example: \c + - hst Connect to "default" database with "current" user on host hst. (Omitted values can be treated as "current".) \c + + hst - Connect to "default" database with "default" user on host hst on "current" port. So we'll still have chance to get back to the libpq defaults. Regards. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] psql patch: new host/port without leaving session
Neil Conway <[EMAIL PROTECTED]> writes: > One question about behavior: in the attached patch, omitting an argument > to \connect or specifying "-" are treated equivalently -- the value for > that parameter from the previous connection is used, otherwise NULL (for > the libpq default). Is this what people want? Yes, that's the behavior I'd expect. The traditional \c behavior for the two longstanding options (dbname and username) was exactly that, no? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] psql patch: new host/port without leaving session
On Sun, 2006-03-12 at 19:59 +0200, Volkan YAZICI wrote:
> I've written do_connect() and \c handling part from scratch in the
> attached patch.
Attached is a revised version of this patch. I rewrote most of the code,
because the existing stuff was in pretty bad style IMHO. I haven't
updated the documentation yet, but I'll do that if no one objects to
this version of the patch.
One question about behavior: in the attached patch, omitting an argument
to \connect or specifying "-" are treated equivalently -- the value for
that parameter from the previous connection is used, otherwise NULL (for
the libpq default). Is this what people want? (One possible complaint is
that once you specify a parameter, you can't get back to the libpq
default without specifying it explicitly.)
-Neil
*** src/bin/psql/command.c b1305764d53ec9138de3c55ec3475a4d8a3190d9
--- src/bin/psql/command.c e570b6eb0b6ade25461b88aca5bbef2e75d27c00
***
*** 55,61
PsqlScanState scan_state,
PQExpBuffer query_buf);
static bool do_edit(const char *filename_arg, PQExpBuffer query_buf);
! static bool do_connect(const char *new_dbname, const char *new_user, const char *new_host, const char *new_port);
static bool do_shell(const char *command);
--- 55,61
PsqlScanState scan_state,
PQExpBuffer query_buf);
static bool do_edit(const char *filename_arg, PQExpBuffer query_buf);
! static bool do_connect(char *dbname, char *user, char *host, char *port);
static bool do_shell(const char *command);
***
*** 154,159
--- 154,192
}
/*
+ * Read and interpret an argument to the \connect slash command.
+ */
+ static char *
+ read_connect_arg(PsqlScanState scan_state)
+ {
+ char *result;
+ char quote;
+
+ /*
+ * Ideally we should treat the arguments as SQL identifiers. But
+ * for backwards compatibility with 7.2 and older pg_dump files,
+ * we have to take unquoted arguments verbatim (don't downcase
+ * them). For now, double-quoted arguments may be stripped of
+ * double quotes (as if SQL identifiers). By 7.4 or so, pg_dump
+ * files can be expected to double-quote all mixed-case \connect
+ * arguments, and then we can get rid of OT_SQLIDHACK.
+ */
+ result = psql_scan_slash_option(scan_state, OT_SQLIDHACK, "e, true);
+
+ if (!result)
+ return NULL;
+
+ if (quote)
+ return result;
+
+ if (*result == '\0' || strcmp(result, "-") == 0)
+ return NULL;
+
+ return result;
+ }
+
+
+ /*
* Subroutine to actually try to execute a backslash command.
*/
static backslashResult
***
*** 188,204
free(opt);
}
! /*--
! * \c or \connect -- connect to new database or as different user,
! * and/or new host and/or port
*
! * \c foo bar [-] [-]connect to db "foo" as user "bar" on current host and port
! * \c foo [-] [-] [-] connect to db "foo" as current user on current host and port
! * \c - bar [-] [-] connect to current db as user "bar" on current host and port
! * \c - - host.domain.tld [-] connect to default db as default user on host.domain.tld on default port
! * \c - - - connect to default db as default user on default host at port
! * \c connect to default db as default user
! *--
*/
else if (strcmp(cmd, "c") == 0 || strcmp(cmd, "connect") == 0)
{
--- 221,242
free(opt);
}
! /*
! * \c or \connect -- connect to database using the specified parameters.
*
! * \c dbname user host port
! *
! * If any of these parameters are omitted or specified as '-', the
! * current value of the parameter will be used instead. If the
! * parameter has no current value, the default value for that
! * parameter will be used. Some examples:
! *
! * \c - - hst Connect to current database on current port of
! * host "hst" as current user.
! * \c - usr - prt Connect to current database on "prt" port of current
! * host as user "usr".
! * \c dbs Connect to "dbs" database on current port of current
! * host as current user.
*/
else if (strcmp(cmd, "c") == 0 || strcmp(cmd, "connect") == 0)
{
***
*** 206,233
*opt2,
*opt3,
*opt4;
- char opt1q,
- opt2q,
- opt3q,
- opt4q;
! /*
! * Ideally we should treat the arguments as SQL identifiers. But for
! * backwards compatibility with 7.2 and older pg_dump files, we have
! * to take unquoted arguments verbatim (don't downcase them). For now,
! * double-quoted arguments may be stripped of double quotes (as if SQL
! * identifiers). By 7.4 or so, pg_dump files can be expected to
! * double-quote all mixed-case \connect arguments, and then we can get
! * rid of OT_SQLIDHACK.
! */
! opt1 = psql_scan_slash_option(scan_state,
! OT_SQLIDHACK, &opt1q, true);
! opt2 = psql
Re: [PATCHES] psql patch: new host/port without leaving session
Hi,
I've written do_connect() and \c handling part from scratch in the
attached patch. Here are some features introduced:
- \c syntax is extended. (See comment lines just above \c stuff.)
- do_connect() AI (like used for prompting password or informing
client about connect attempt's result.) improved.
- Some code clean up.
If you'd agree with the style, I'll add patch for the documentation and
PO files too.
Regards.
P.S. Patch passed regressions tests on CVS tip.
On Dec 13 04:29, David Fetter wrote:
> Please find enclosed a patch that lets you use \c to connect
> (optionally) to a new host and port without exiting psql. This
> eliminates, IMHO, a surprise in that you can now connect to PostgreSQL
> on a differnt machine from the one where you started your session.
> This should help people who use psql as an administrative tool.
Index: src/bin/psql/command.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.164
diff -c -r1.164 command.c
*** src/bin/psql/command.c 5 Mar 2006 15:58:51 - 1.164
--- src/bin/psql/command.c 12 Mar 2006 17:42:10 -
***
*** 188,215
free(opt);
}
! /*--
!* \c or \connect -- connect to new database or as different user,
!* and/or new host and/or port
*
!* \c foo bar [-] [-]connect to db "foo" as user "bar" on
current host and port
!* \c foo [-] [-] [-] connect to db "foo" as current user on
current host and port
!* \c - bar [-] [-] connect to current db as user "bar" on
current host and port
!* \c - - host.domain.tld [-] connect to default db as default user on
host.domain.tld on default port
!* \c - - - connect to default db as default user on
default host at port
!* \c connect to default db as default user
!*--
*/
else if (strcmp(cmd, "c") == 0 || strcmp(cmd, "connect") == 0)
{
! char *opt1,
! *opt2,
! *opt3,
! *opt4;
! charopt1q,
! opt2q,
! opt3q,
! opt4q;
/*
* Ideally we should treat the arguments as SQL identifiers.
But for
--- 188,221
free(opt);
}
! /*
!* \c or \connect -- connect to database with using specified
parameters.
!*
!* \c dbname user host port
!*
!* Place a `-' instead of the related parameter to make it use its
current
!* value. (If there doesn't exist any current value for the specified
!* parameter, it won't get included in the connection string.)
*
!* Here are some examples:
!*
!* \c - - hst Connect to current database on current port of
!* host "hst" as current user.
!* \c - usr - prt Connect to current database on "prt" port of
current
!* host as user "usr".
!* \c dbs Connect to "dbs" database on current
port of current
!* host as current user.
*/
else if (strcmp(cmd, "c") == 0 || strcmp(cmd, "connect") == 0)
{
! char*opt1,
! *opt2,
! *opt3,
! *opt4;
! char opt1q,
!opt2q,
!opt3q,
!opt4q;
/*
* Ideally we should treat the arguments as SQL identifiers.
But for
***
*** 220,272
* double-quote all mixed-case \connect arguments, and then we
can get
* rid of OT_SQLIDHACK.
*/
! opt1 = psql_scan_slash_option(scan_state,
!
OT_SQLIDHACK, &opt1q, true);
! opt2 = psql_scan_slash_option(scan_state,
!
OT_SQLIDHACK, &opt2q, true);
! opt3 = psql_scan_slash_option(scan_state,
!
OT_SQLIDHACK, &opt3q, true);
! opt4 = psql_scan_slash_option(scan_state,
!
OT_SQLIDHACK, &opt4q, true);
!
! if (opt4)
! /* gave port */
! success = do_connect(!opt1q && (strcmp(opt1, "-
Re: [PATCHES] psql patch: new host/port without leaving session
Patch applied. Thanks. --- David Fetter wrote: > Folks, > > Please find enclosed a patch that lets you use \c to connect > (optionally) to a new host and port without exiting psql. This > eliminates, IMHO, a surprise in that you can now connect to PostgreSQL > on a differnt machine from the one where you started your session. > This should help people who use psql as an administrative tool. > > Cheers, > D > -- > David Fetter [EMAIL PROTECTED] http://fetter.org/ > phone: +1 415 235 3778 > > Remember to vote! [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] psql patch for displaying the username when asking password
Adrian Maier wrote: > On 6/30/05, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > > Am Donnerstag, 30. Juni 2005 09:34 schrieb Adrian Maier: > > > The attached patch modifies the message displayed by psql > > > when asking the password "Password: " > > > to include the username as well: "Password for user postgres : ". > > > > I can't decode your attachment so I don't know if this is a typo or > > actually in the patch, but there shouldn't be a space after the user name. > > There was a space there. I've removed the space between > username and colons.The space after the colons is ok, I hope ? > > I'm attaching the modified patch. I made this adjustment in the applied version. Thanks. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] psql patch for displaying the username when asking password
Patch adjusted slightly, attached, and applied. Thanks.
---
Adrian Maier wrote:
> On 6/30/05, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, 30. Juni 2005 09:34 schrieb Adrian Maier:
> > > The attached patch modifies the message displayed by psql
> > > when asking the password "Password: "
> > > to include the username as well: "Password for user postgres : ".
> >
> > I can't decode your attachment so I don't know if this is a typo or
> > actually in the patch, but there shouldn't be a space after the user name.
>
> There was a space there. I've removed the space between
> username and colons.The space after the colons is ok, I hope ?
>
> I'm attaching the modified patch.
>
> Cheers,
> Adrian Maier
[ Attachment, skipping... ]
>
> ---(end of broadcast)---
> TIP 7: don't forget to increase your free space map settings
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.150
diff -c -c -r1.150 command.c
*** src/bin/psql/command.c 18 Jul 2005 20:57:53 - 1.150
--- src/bin/psql/command.c 25 Jul 2005 17:13:42 -
***
*** 911,916
--- 911,917
const char *dbparam = NULL;
const char *userparam = NULL;
const char *pwparam = NULL;
+ char *password_prompt = NULL;
char *prompted_password = NULL;
boolneed_pass;
boolsuccess = false;
***
*** 930,938
else
userparam = new_user;
/* need to prompt for password? */
if (pset.getPassword)
! pwparam = prompted_password = simple_prompt("Password: ", 100,
false);
/*
* Use old password (if any) if no new one given and we are
--- 931,948
else
userparam = new_user;
+ if (userparam == NULL)
+ password_prompt = strdup("Password: ");
+ else
+ {
+ password_prompt = malloc(strlen("Password for user %s: ") - 2 +
+
strlen(userparam) + 1);
+ sprintf(password_prompt,"Password for user %s: ", userparam);
+ }
+
/* need to prompt for password? */
if (pset.getPassword)
! pwparam = prompted_password = simple_prompt(password_prompt,
100, false);
/*
* Use old password (if any) if no new one given and we are
***
*** 956,966
need_pass = true;
free(prompted_password);
prompted_password = NULL;
! pwparam = prompted_password = simple_prompt("Password:
", 100, false);
}
} while (need_pass);
free(prompted_password);
/*
* If connection failed, try at least keep the old one. That's
--- 966,977
need_pass = true;
free(prompted_password);
prompted_password = NULL;
! pwparam = prompted_password =
simple_prompt(password_prompt, 100, false);
}
} while (need_pass);
free(prompted_password);
+ free(password_prompt);
/*
* If connection failed, try at least keep the old one. That's
Index: src/bin/psql/startup.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.119
diff -c -c -r1.119 startup.c
*** src/bin/psql/startup.c 14 Jul 2005 08:42:37 - 1.119
--- src/bin/psql/startup.c 25 Jul 2005 17:13:42 -
***
*** 106,111
--- 106,112
char *username = NULL;
char *password = NULL;
+ char *password_prompt = NULL;
boolneed_pass;
set_pglocale_pgservice(argv[0], "psql");
***
*** 188,195
username = pg_strdup(options.username);
}
if (pset.getPassword)
! password = simple_prompt("Password: ", 100, false);
/* loop until we have a password if requested by backend */
do
--- 189,205
username = pg_strdup(options.username);
}
+ if (options.username == NULL)
+ password_prompt = strdup("Password: ");
+ else
+ {
+ password_prompt = malloc(strlen("Password for user %s: ") - 2 +
+
Re: [PATCHES] psql patch for displaying the username when asking password
On 6/30/05, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Am Donnerstag, 30. Juni 2005 09:34 schrieb Adrian Maier: > > The attached patch modifies the message displayed by psql > > when asking the password "Password: " > > to include the username as well: "Password for user postgres : ". > > I can't decode your attachment so I don't know if this is a typo or > actually in the patch, but there shouldn't be a space after the user name. There was a space there. I've removed the space between username and colons.The space after the colons is ok, I hope ? I'm attaching the modified patch. Cheers, Adrian Maier psql_password_prompt_v2.diff.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] psql patch for displaying the username when asking password
Am Donnerstag, 30. Juni 2005 09:34 schrieb Adrian Maier: > The attached patch modifies the message displayed by psql > when asking the password "Password: " > to include the username as well: "Password for user postgres : ". I can't decode your attachment so I don't know if this is a typo or actually in the patch, but there shouldn't be a space after the user name. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
