-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
-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,' ||
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?
-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:
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
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
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:
=?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
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
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
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
Ü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
12 matches
Mail list logo
