Re: [HACKERS] [pgadmin-hackers] Client-side password encryption
-Original Message- From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED] Sent: 20 December 2005 01:33 To: Dave Page Cc: Tom Lane; Peter Eisentraut; pgsql-hackers@postgresql.org; Andreas Pflug Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password encryption By the way, I've already implemented this in phpPgAdmin trivially using the md5() function. I can't be bothered using a C library function :D Yeah, figured you probably would :-) /D ---(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
[HACKERS] Disparity in search_path SHOW and SET
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm trying to figure out a way to modify the search_path temporarily, but
the $user construct is making this difficult. I need to prepend a schema
to the path. This works fine:
SELECT set_config('search_path', '$schema,' || current_setting('search_path'),
true);
...but does not last outside of a transaction.
The problem is really that the output of SHOW search_path cannot be fed
back into SET search_path if the search_path contains the string $user.
My only option appears to be to have the application parse the string returned
from SHOW search_path, quote the dollar-values, and rebuild the string. Is
there an easier way?
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200512201205
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-
iD8DBQFDqDvOvJuQZxSWSsgRAgUKAKDrRJoCfe8M7Fe2mi+/KFlEKKn+fQCgthpw
jPV95zpbejZsaRvIBeLd8rM=
=xRza
-END PGP SIGNATURE-
---(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: [HACKERS] Disparity in search_path SHOW and SET
Greg Sabino Mullane [EMAIL PROTECTED] writes:
This works fine:
SELECT set_config('search_path', '$schema,' ||
current_setting('search_path'), true);
...but does not last outside of a transaction.
Well, sure, because you told it to. Why isn't the last parameter
false?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Disparity in search_path SHOW and SET
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, sure, because you told it to. Why isn't the last parameter false? Thanks. I knew I was overlooking something. I've obviously been staring at the code too long. :) Still, would it make more sense for SHOW search_path to return this: $user,public - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200512201227 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFDqD83vJuQZxSWSsgRAj1gAKDIRGqzD7zORJQwrxLM+oKWOiAPKgCg9/xK OGZIoWEnLdw+Qi71lKbCg0g= =0dBJ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Disparity in search_path SHOW and SET
Greg Sabino Mullane [EMAIL PROTECTED] writes: Still, would it make more sense for SHOW search_path to return this: $user,public Can't get excited about it. SHOW is meant for human consumption, not programs ... regards, tom lane ---(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: [HACKERS] Automatic function replanning
It seems to me like there are two classes of problems here: 1) Simply invalidating plans made with out of date statistics. 2) Using run-time collected data to update the plan to something more intelligent. It also seems like #1 would be fairly straightforward and simple whereas #2 would be much more complex. #1 would do me a world of good and probably other people as well. Postgres's query planning has always been fine for me, or at least I have always been able to optimize my queries when I've got a representative data set to work with. Query plan caching only gets me when the query plan is created before the statistics are present to create a good plan. Just one users 2 cents. - Rick Gigger On Dec 19, 2005, at 12:00 PM, Jim C. Nasby wrote: On Sat, Dec 17, 2005 at 01:07:10PM -0500, Bruce Momjian wrote: Jim C. Nasby wrote: Is cardinality the only thing we'd need to worry about? My idea was actually to track the amount of work normally required by a stored query plan, and if a query uses that plan but requires a very different amount of work it's a good indication that we either need to replan or store multiple plans for that query. Though if we're certain that cardinality is the only thing that could make a cached plan go bad it would certainly simplify things greatly. This gets into another area of re-optimizing when the executor finds that the actual tables don't match the optimizer estimates. I think we decided that was too hard/risky, but invalidating the plan might help, though I am thinking re-planning might just generate the same plan as before. I think something would need to have happened since the last planning, like ANALYZE or something. Well, in the stored plan case, presumably what's changed is one of the bound parameters. And if we want to be sophisticated about it, we won't just throw out the old plan; rather we'll try and figure out what parameter it is that's wanting a different plan. Updated TODO: * Flush cached query plans when the dependent objects change, when the cardinality of parameters changes dramatically, or when new ANALYZE statistics are available Probably worth pointing to this therad in the TODO... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] status of concurrent VACUUM patch ...
i was just wondering about the status of hannu's concurrent vacuum patch. are there any plans to integrate this or are there still improvements which have to be made? many thanks, hans-juergen schoenig ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] status of concurrent VACUUM patch ...
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes: i was just wondering about the status of hannu's concurrent vacuum patch. are there any plans to integrate this I still don't trust it (assuming that you're thinking of the same patch I am). regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] localization problem (and solution)
Manuel Sugawara masm@fciencias.unam.mx writes: While there are reasons to argue that's Perl fault, IMO, an environment that reflects the current state of the host program is a good compromise, and behave environment-consistent is also a good compromise for libperl (I think some applications of libperl will get really upset if this compromise is broken by the library.) I looked into this a bit more, and it seems the issue is that libperl will do setlocale(LC_ALL, ); the first time any locale-related Perl function is invoked. To defend ourselves against that, we'd have to set more environment variables than just LC_COLLATE and LC_CTYPE. What I'm thinking about is: * during startup, putenv(LC_ALL=C) and unsetenv any other LC_ variables that may be lurking, except LC_MESSAGES. * copy LC_COLLATE and LC_CTYPE into the environment when we get them from pg_control, as Manuel suggested. * in locale_messages_assign(), set the environment variable on all platforms not just Windows. You could still break the backend by doing setlocale explicitly in plperlu functions, but that's why it's an untrusted language ... Comments? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] I am back online again
As part of a network reconfiguration at my home, I was offline from Monday at 9AM to Tuesday at 2PM EST. My backup ISP did a poor job and rejected all my email sent to me during that period. If you emailed and got a rejection, please resent it now. I have moved to a new backup ISP that hopefully will be more reliable in the future. Sorry again. I will read the email archives to catch up. -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] localization problem (and solution)
Tom Lane writes: I looked into this a bit more, and it seems the issue is that libperl will do setlocale(LC_ALL, ); the first time any locale-related Perl function is invoked. To defend ourselves against that, we'd have to set more environment variables than just LC_COLLATE and LC_CTYPE. What I'm thinking about is: * during startup, putenv(LC_ALL=C) and unsetenv any other LC_ variables that may be lurking, except LC_MESSAGES. * copy LC_COLLATE and LC_CTYPE into the environment when we get them from pg_control, as Manuel suggested. I'm afraid having LC_ALL in the environment at this time would still do the wrong thing on setlocale(LC_ALL, ); since a LC_ALL environment variable overrides the other categories. Maybe setting LANG instead would be a better choice? regards, Andreas -- ---(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: [HACKERS] status of concurrent VACUUM patch ...
Ühel kenal päeval, T, 2005-12-20 kell 17:18, kirjutas Tom Lane: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes: i was just wondering about the status of hannu's concurrent vacuum patch. are there any plans to integrate this I still don't trust it (assuming that you're thinking of the same patch I am). What could I do to increase your trust in it ? Could you think of any specific case it could break ? Or any specific tests to check for it ? I attach the version of the patch for 8.1.0 for anyone interested in checking it. -- Hannu ---(end of broadcast)--- TIP 6: explain analyze is your friend
