[PATCHES] psql patch for displaying the username when asking password
Hello all,
The attached patch modifies the message displayed by psql
when asking the password Password:
to include the username as well: Password for user postgres : .
Displaying the username is useful when running sql scripts
which are setting the session authorization (like the dump scripts
generated by older versions of pg_dump) and you don't have all the
usernames/passwords in ~/.pgpass.
In such cases it can happen that psql is asking several times :
Password:
Password:
Password:
Password:
and you don't know whether it's asking the pasword of the 'postgres' user
or the password of user that is importing the data .
I have the feeling that asking for Password: several times no longer
happens when running scripts generated by recent versions of pg_dump.
However, the patch might be useful for people who are upgrading .
Cheers,
Adrian Maier
*** ./src/bin/psql/command.c.orig 2005-06-30 09:06:41.953634513 +0300
--- ./src/bin/psql/command.c 2005-06-30 09:49:41.216208791 +0300
***
*** 912,917
--- 912,918
const char *dbparam = NULL;
const char *userparam = NULL;
const char *pwparam = NULL;
+ char *password_prompt = NULL;
char *prompted_password = NULL;
bool need_pass;
bool success = false;
***
*** 931,939
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
--- 932,951
else
userparam = new_user;
+ if (userparam == NULL)
+ {
+ password_prompt = malloc(strlen(Password: )+1);
+ sprintf(password_prompt,Password: );
+ }
+ else
+ {
+ password_prompt = malloc(strlen(userparam)+30);
+ 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
***
*** 957,967
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
--- 969,980
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
*** ./src/bin/psql/startup.c.orig 2005-06-30 09:06:34.816798114 +0300
--- ./src/bin/psql/startup.c 2005-06-30 09:22:50.487536877 +0300
***
*** 106,111
--- 106,112
char *username = NULL;
char *password = NULL;
+ char *password_prompt = NULL;
bool need_pass;
set_pglocale_pgservice(argv[0], psql);
***
*** 187,194
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
--- 188,206
username = pg_strdup(options.username);
}
+ if (username == NULL)
+ {
+ password_prompt = malloc(strlen(Password: )+1);
+ strcat(password_prompt,Password: );
+ }
+ else
+ {
+ password_prompt = malloc(strlen(username)+30);
+ sprintf(password_prompt,Password for user %s : ,username);
+ }
+
if (pset.getPassword)
! password = simple_prompt(password_prompt, 100, false);
/* loop until we have a password if requested by backend */
do
***
*** 206,217
need_pass = true;
free(password);
password = NULL;
! password = simple_prompt(Password: , 100, false);
}
} while (need_pass);
free(username);
free(password);
if (PQstatus(pset.db) == CONNECTION_BAD)
{
--- 218,230
need_pass = true;
free(password);
password = NULL;
! password = simple_prompt(password_prompt, 100, false);
}
} while (need_pass);
free(username);
free(password);
+ free(password_prompt);
if (PQstatus(pset.db) == CONNECTION_BAD)
{
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
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
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] Dbsize backend integration
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 29 June 2005 12:46 To: Dave Page Cc: PostgreSQL-patches; PostgreSQL-development Subject: Re: [PATCHES] Dbsize backend integration I have a new idea --- pg_storage_size(). I'm not against that one, but I think Tom's point is vaild. I cannot think of anything better at the moment though (maybe pg_component_size, but that's equally random) :-( Anyone else? Please? Someone? Anyone? :-) That would do just the toast/index/heap, and pg_relation_size() gets a total of them all, and only works on heap, no index or toast. The totalling version (whatever it ends up being called) should definitely work on toast tables, as it is a legitimate use case to want to see the size of such a table and it's indexes, independent of the owner table. There is no need for it to work on an index though, however, it will return the right answer if it is used that way, so I think that trying to prevent it will be unecessary code that simply slows down the majority of invocations of the function for no benefit. Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Dbsize backend integration
On Jun 30, 2005, at 5:48 PM, Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 29 June 2005 12:46 snip / I have a new idea --- pg_storage_size(). I'm not against that one, but I think Tom's point is vaild. I cannot think of anything better at the moment though (maybe pg_component_size, but that's equally random) :-( Anyone else? Please? Someone? Anyone? :-) I'm still unclear as to what exactly is trying to be captured by the names, so I'll just throw some out and see if they're intuitive to anyone. pg_table_extensions_size() pg_table_support_size() pg_relation_extensions_size() pg_relation_support_size() pg_relation_extended_size() My two yen... if that :) Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Dbsize backend integration
I have a new idea --- pg_storage_size(). I'm not against that one, but I think Tom's point is vaild. I cannot think of anything better at the moment though (maybe pg_component_size, but that's equally random) :-( Anyone else? Please? Someone? Anyone? :-) Maybe pg_trait_size() or pg_property_size() will do? -- Victor Msg sent via @Mail ISP MiTS - http://www.mits.lv/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Dbsize backend integration
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 30 June 2005 10:29 To: Bruce Momjian; Dave Page Cc: PostgreSQL-patches; PostgreSQL-development Subject: Re: [PATCHES] Dbsize backend integration Maybe pg_trait_size() or pg_property_size() will do? I don't think property is right. What's your thinking for trait though? Regards, Dave ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Dbsize backend integration
-Original Message- From: Michael Glaesemann [mailto:[EMAIL PROTECTED] Sent: 30 June 2005 10:01 To: Dave Page Cc: PostgreSQL-patches; PostgreSQL-development Subject: Re: [PATCHES] Dbsize backend integration I'm still unclear as to what exactly is trying to be captured by the names, so I'll just throw some out and see if they're intuitive to anyone. Thanks Michael. We have 2 functions - 1 returns the on disk size of a table or index without any additional parts such as indexes or toast tables. The other function returns the total on disk size of a table and all associated indexes and toast tables (and any indexes they might have). The current names are pg_relation_size() for the first function, and pg_table_size() for the second. pg_table_extensions_size() pg_table_support_size() pg_relation_extensions_size() pg_relation_support_size() pg_relation_extended_size() Hmm, none of those really stand out - but thanks anyway. More are welcome :-) Regards, Dave ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Dbsize backend integration
Dave Page dpage@vale-housing.co.uk writes: Thanks Michael. We have 2 functions - 1 returns the on disk size of a table or index without any additional parts such as indexes or toast tables. The other function returns the total on disk size of a table and all associated indexes and toast tables (and any indexes they might have). The current names are pg_relation_size() for the first function, and pg_table_size() for the second. That seems to me to work perfectly fine. Relation is being used here in its PG-jargon sense, that is an object described by one row of pg_class, and table is being used from the user's point of view. Or at least sort of --- I think most users know enough to distinguish tables and indexes. We can figure that the toast table and its index ought to be considered part of the base table, though, since the user doesn't have a choice about those. I've not been following the thread closely, so maybe this was already proposed and rejected, but what about: pg_relation_size: size of exactly the relation you point it at (table, index, toast table, whatever) pg_table_size: point it at heap, get size of heap+toast+toast_index pg_index_size: point it at heap, get size of all indexes for heap (excludes toast index) pg_total_size: point it at heap, get table_size + index_size regards, tom lane ---(end of broadcast)--- TIP 3: 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] Dbsize backend integration
Dave Page dpage@vale-housing.co.uk writes: I've not been following the thread closely, so maybe this was already proposed and rejected, but what about: [4 functions] That moves the goal posts somewhat. Fair enough. The two you described are OK by me. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Constraint Exclusion (Partitioning) - Initial Review
On Mon, 2005-06-27 at 01:41 +0100, Simon Riggs wrote: I enclose a fully working implementation of Constraint Exclusion, a very basic form of Partitioning. Initial review is requested, to allow us all to assess what further work is required on this prior to Beta freeze. Patch against current cvstip; passes make check and all special tests. Has this patch been registered for review? I haven't heard anything. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Dbsize backend integration
Dave Page wrote: That would do just the toast/index/heap, and pg_relation_size() gets a total of them all, and only works on heap, no index or toast. The totalling version (whatever it ends up being called) should definitely work on toast tables, as it is a legitimate use case to want to see the size of such a table and it's indexes, independent of the owner table. There is no need for it to work on an index though, however, it will return the right answer if it is used that way, so I think that trying to prevent it will be unecessary code that simply slows down the majority of invocations of the function for no benefit. Agreed. -- 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 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] Constraint Exclusion (Partitioning) - Initial Review requested
Simon Riggs wrote: On Mon, 2005-06-27 at 01:41 +0100, Simon Riggs wrote: I enclose a fully working implementation of Constraint Exclusion, a very basic form of Partitioning. Initial review is requested, to allow us all to assess what further work is required on this prior to Beta freeze. Patch against current cvstip; passes make check and all special tests. Has this patch been registered for review? I haven't heard anything. Well, it has been three days, and no one said anything, so I will put it the queue. -- 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 7: don't forget to increase your free space map settings
Re: [PATCHES] Dbsize backend integration
[EMAIL PROTECTED] wrote: I have a new idea --- pg_storage_size(). I'm not against that one, but I think Tom's point is vaild. I cannot think of anything better at the moment though (maybe pg_component_size, but that's equally random) :-( Anyone else? Please? Someone? Anyone? :-) Maybe pg_trait_size() or pg_property_size() will do? I don't think so. I think trait and property suggests an aspect of the object, so saying trait/property size is saying I am talking about an aspect of the object, while for a heap, its size is really its size, it isn't an aspect of its size. -- 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: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] Dbsize backend integration
Bruce Momjian pgman@candle.pha.pa.us writes: I don't think so. I think trait and property suggests an aspect of the object, so saying trait/property size is saying I am talking about an aspect of the object, while for a heap, its size is really its size, it isn't an aspect of its size. I haven't been following this discussion but, uh, does the fact that I have absolutely no clue what pg_trait_size() or pg_property_size() would be measuring count for anything? My best guess here is that it's for measuring the space taken up by a column which doesn't make a lot of sense. I think you need to think about unambiguous words that help the user understand what the function does; words that the user might guess if they were looking for a function to do that, whatever that is. Not words that are sufficiently vague as to include whatever it's actually doing but offer no clue what that is. There are an infinite number of such words to pick and no way for the user to figure out what he or she is looking for. -- greg ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] ecpg: check for strdup() failure
Attached is a trivial improvement to ecpg's pgtypeslib: (1) `pstr' must
be non-NULL in this function, so no need to check for it (2) we should
check the return value of pgtypes_strdup(). Patch from Eric Astor at
EDB, with slight cleanup by myself, to fix a Coverity report.
Barring any objections I'll apply this to HEAD later today.
-Neil
Index: src/interfaces/ecpg/pgtypeslib/dt_common.c
===
RCS file: /var/lib/cvs/pgsql/src/interfaces/ecpg/pgtypeslib/dt_common.c,v
retrieving revision 1.23
diff -c -r1.23 dt_common.c
*** src/interfaces/ecpg/pgtypeslib/dt_common.c 24 May 2005 02:09:45 - 1.23
--- src/interfaces/ecpg/pgtypeslib/dt_common.c 30 Jun 2005 05:57:10 -
***
*** 2669,2676
if (!pstr_end)
{
/* there was an error, no match */
! err = 1;
! return err;
}
last_char = *pstr_end;
*pstr_end = '\0';
--- 2669,2675
if (!pstr_end)
{
/* there was an error, no match */
! return 1;
}
last_char = *pstr_end;
*pstr_end = '\0';
***
*** 2699,2706
err = 1;
break;
case PGTYPES_TYPE_STRING_MALLOCED:
! if (pstr)
! scan_val-str_val = pgtypes_strdup(*pstr);
}
if (strtol_end *strtol_end)
*pstr = strtol_end;
--- 2698,2707
err = 1;
break;
case PGTYPES_TYPE_STRING_MALLOCED:
! scan_val-str_val = pgtypes_strdup(*pstr);
! if (scan_val-str_val == NULL)
! err = 1;
! break;
}
if (strtol_end *strtol_end)
*pstr = strtol_end;
---(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
[PATCHES] ecpg: numeric_div error handling
This patch adds some missing error handling to PGTYPESnumeric_div() in
ecpg's pgtypeslib: (1) we need to check the return value of sub_abs()
(2) we need to check the return value of 4 calls to digitbuf_alloc().
Per Coverity static analysis by EDB.
Barring any objections I'll apply this to CVS later today.
-Neil
Index: src/interfaces/ecpg/pgtypeslib/numeric.c
===
RCS file: /var/lib/cvs/pgsql/src/interfaces/ecpg/pgtypeslib/numeric.c,v
retrieving revision 1.21
diff -c -r1.21 numeric.c
*** src/interfaces/ecpg/pgtypeslib/numeric.c 24 May 2005 02:09:45 - 1.21
--- src/interfaces/ecpg/pgtypeslib/numeric.c 1 Jul 2005 01:47:51 -
***
*** 1096,1101
--- 1096,1103
int stat = 0;
int rscale;
int res_dscale = select_div_scale(var1, var2, rscale);
+ int err = -1;
+ NumericDigit *tmp_buf;
/*
* First of all division by zero check
***
*** 1143,1148
--- 1145,1152
divisor[1].rscale = var2-ndigits;
divisor[1].sign = NUMERIC_POS;
divisor[1].buf = digitbuf_alloc(ndigits_tmp);
+ if (divisor[1].buf == NULL)
+ goto done;
divisor[1].digits = divisor[1].buf;
divisor[1].digits[0] = 0;
memcpy((divisor[1].digits[1]), var2-digits, ndigits_tmp - 1);
***
*** 1155,1168
dividend.rscale = var1-ndigits;
dividend.sign = NUMERIC_POS;
dividend.buf = digitbuf_alloc(var1-ndigits);
dividend.digits = dividend.buf;
memcpy(dividend.digits, var1-digits, var1-ndigits);
/*
! * Setup the result
*/
digitbuf_free(result-buf);
! result-buf = digitbuf_alloc(res_ndigits + 2);
res_digits = result-buf;
result-digits = res_digits;
result-ndigits = res_ndigits;
--- 1159,1179
dividend.rscale = var1-ndigits;
dividend.sign = NUMERIC_POS;
dividend.buf = digitbuf_alloc(var1-ndigits);
+ if (dividend.buf == NULL)
+ goto done;
dividend.digits = dividend.buf;
memcpy(dividend.digits, var1-digits, var1-ndigits);
/*
! * Setup the result. Do the allocation in a temporary buffer
! * first, so we don't free result-buf unless we have successfully
! * allocated a buffer to replace it with.
*/
+ tmp_buf = digitbuf_alloc(res_ndigits + 2);
+ if (tmp_buf == NULL)
+ goto done;
digitbuf_free(result-buf);
! result-buf = tmp_buf;
res_digits = result-buf;
result-digits = res_digits;
result-ndigits = res_ndigits;
***
*** 1201,1206
--- 1212,1219
memcpy(divisor[guess], divisor[1], sizeof(numeric));
divisor[guess].buf = digitbuf_alloc(divisor[guess].ndigits);
+ if (divisor[guess].buf == NULL)
+ goto done;
divisor[guess].digits = divisor[guess].buf;
for (i = divisor[1].ndigits - 1; i = 0; i--)
{
***
*** 1233,1239
if (guess == 0)
continue;
! sub_abs(dividend, divisor[guess], dividend);
first_nextdigit = dividend.weight - weight_tmp;
first_have = 0;
--- 1246,1253
if (guess == 0)
continue;
! if (sub_abs(dividend, divisor[guess], dividend) != 0)
! goto done;
first_nextdigit = dividend.weight - weight_tmp;
first_have = 0;
***
*** 1269,1283
if (result-ndigits == 0)
result-sign = NUMERIC_POS;
/*
* Tidy up
*/
! digitbuf_free(dividend.buf);
for (i = 1; i 10; i++)
! digitbuf_free(divisor[i].buf);
! result-dscale = res_dscale;
! return 0;
}
--- 1283,1305
if (result-ndigits == 0)
result-sign = NUMERIC_POS;
+ result-dscale = res_dscale;
+ err = 0; /* if we've made it this far, return success */
+
+ done:
/*
* Tidy up
*/
! if (dividend.buf != NULL)
! digitbuf_free(dividend.buf);
!
for (i = 1; i 10; i++)
! {
! if (divisor[i].buf != NULL)
! digitbuf_free(divisor[i].buf);
! }
! return err;
}
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] Users/Groups - Roles
Dear Stephen, Attached please find files and patches associated with moving from the User/Group system currently in place to Roles, as discussed previously. The files are: pg_authid.h New system table, contains role information To be placed in src/include/catalog, replacing pg_shadow.h pg_auth_members.h New system table, contains role/membership information To be placed in src/include/catalog, replacing pg_group.h I've looked very quickly at the patch. ISTM that the proposed patch is a reworking of the user/group stuff, which are both unified for a new role concept where a user is a kind of role and a role can be a member of another role. Well, why not. Some added files seems not to be provided in the patch : sh bzgrep pg_authid.h ./role_2005062701.ctx.patch.bz2 ? src/include/catalog/pg_authid.h ! pg_namespace.h pg_conversion.h pg_database.h pg_authid.h pg_auth_members.h \ ! #include catalog/pg_authid.h ! #include catalog/pg_authid.h ! #include catalog/pg_authid.h ! #include catalog/pg_authid.h ! #include catalog/pg_authid.h ! #include catalog/pg_authid.h + #include catalog/pg_authid.h + #include catalog/pg_authid.h ! #include catalog/pg_authid.h ! #include catalog/pg_authid.h ! #include catalog/pg_authid.h ! #include catalog/pg_authid.h Or maybe I missed something, but I could not find the pg_authid file? the '?' line in the diff seems to suggest an unexpected file. Anyway, from what I can see in the patch it seems that the roles are per cluster, and not per catalog. So this is not so conceptually different from user/group as already provided in pg. What would have been much more interesting for me would be a per catalog role, so that rights could be administrated locally in each database. I'm not sure how to provide such a feature, AFAICS the current version does not give me new abilities wrt right management. Have a nice day, -- Fabien. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] ecpg: numeric_div error handling
Neil Conway wrote: This patch adds some missing error handling to PGTYPESnumeric_div() in ecpg's pgtypeslib: (1) we need to check the return value of sub_abs() (2) we need to check the return value of 4 calls to digitbuf_alloc(). Applied. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] ecpg: check for strdup() failure
Neil Conway wrote: Attached is a trivial improvement to ecpg's pgtypeslib: (1) `pstr' must be non-NULL in this function, so no need to check for it (2) we should check the return value of pgtypes_strdup(). Patch from Eric Astor at EDB, with slight cleanup by myself, to fix a Coverity report. Applied. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
