Re: [PATCHES] [HACKERS] float8 regression failure (HEAD, cygwin)
On 20/07/06, Tom Lane [EMAIL PROTECTED] wrote: Reini Urban [EMAIL PROTECTED] writes: BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is defined also. You sure? INT64_IS_BUSTED should *not* be set in that case --- it's only supposed to be set if we couldn't find any 64-bit-int type at all. As for the regression test failure, it's odd because it looks to me that the actual test output is an exact match to the default float8.out file. I'm not sure why pg_regress chose to report a diff against float8-small-is-zero.out instead. This may be another teething pain of the new pg_regress-in-C code --- could you trace through it and see what's happening? Apparently the regression test is comparing the results/float8.out with expected/float8-small-is-zero.out because of the following line in src/test/regress/resultmap : float8/i.86-pc-cygwin=float8-small-is-zero I've changed that line to : float8/i.86-pc-cygwin=float8 and the regression test ended successfully : All 100 tests passed. I don't know why there are several expected results for the float8 test, depending on the platform. Is the modification ok? I've attached the patch, and cc'ed to pgsql-patches. Cheers, Adrian Maier patch_float8.diff Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] float8 regression failure (HEAD, cygwin)
On 01/08/06, Andrew Dunstan [EMAIL PROTECTED] wrote: Adrian Maier wrote: On 20/07/06, Tom Lane [EMAIL PROTECTED] wrote: Apparently the regression test is comparing the results/float8.out with expected/float8-small-is-zero.out because of the following line in src/test/regress/resultmap : float8/i.86-pc-cygwin=float8-small-is-zero I've changed that line to : float8/i.86-pc-cygwin=float8 and the regression test ended successfully : All 100 tests passed. I don't know why there are several expected results for the float8 test, depending on the platform. Is the modification ok? I've attached the patch, and cc'ed to pgsql-patches. The problem with this is that we have another Cygwin member on buildfarm which passes the tests happily, and will thus presumably fail if we make this patch. You are running Cygwin 1.5.21 and the other buildfarm member is running 1.5.19, so that is possibly the difference. This is indeed a problem. It would be difficult or even impossible to use different expected results for different versions of cygwin. Maybe we need to abandon trying to map float8 results exactly in the resultmap file, and just let pg_regress pick the best fit as we do with some other tests. Oh, is it possible to do that? That sounds great. Which other tests work like that? Cheers, Adrian Maier ---(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] [HACKERS] float8 regression failure (HEAD, cygwin)
On 01/08/06, Tom Lane [EMAIL PROTECTED] wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Maybe we need to abandon trying to map float8 results exactly in the resultmap file, and just let pg_regress pick the best fit as we do with some other tests. I thought about that too but it seems a very bad idea. small-is-zero is distinctly less correct than the regular output, and I don't think we want pg_regress to be blindly accepting it as OK on any platform. Perhaps we could stick a version check into the resultmap lookup? It'd likely have been painful on the shell script implementation but now that the code is in C I think we have lots of flexibility. There's no need to feel bound by the historical resultmap format. However this is all premature unless we can verify that cgywin's strtod() complains about float underflow after version so-and-so. Do they publish a detailed change log? There are links to the last few releases on their home page http://www.cygwin.com , in the News section. -- Adrian Maier ---(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
[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
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
