Ü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 y
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 an
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
Manuel Sugawara 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
>
=?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,
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: H
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
"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
-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:
"$use
"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
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
> -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
>
12 matches
Mail list logo
