I am writing to you all just to inform you of a bug(probably), that I
came across while trying to install PostgreSQL 8.1.0-2 and 8.1.1-1 on
WinXP with SP2, using the PostgreSQL installer.
I had done a windows clean install and then installed straight away
PostgreSQL 8.0.4. It was the only
Andreas Seltenreich [EMAIL PROTECTED] writes:
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.
Doh, of course, I was misremembering the precedence. So we need
Tom Lane said:
Andreas Seltenreich [EMAIL PROTECTED] writes:
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.
Doh, of course, I was misremembering the
Martin Pitt [EMAIL PROTECTED] writes:
Tom Lane [2005-12-20 16:39 -0500]:
We could doubtless improve make_relative_path to some extent, but the
mess you have above seems impossible to deal with. How is a mere
program supposed to deduce where things were moved to, given only
knowledge of the
Andrew Dunstan [EMAIL PROTECTED] writes:
We need to test any solution carefully on Windows, which deals with locales
very differently from *nix, and where we still have some known locale issues
Right, of course. I was thinking that this change might actually bring
the Windows and Unix code
Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] writes:
We need to test any solution carefully on Windows, which deals with
locales very differently from *nix, and where we still have some known
locale issues
Right, of course. I was thinking that this change might actually bring
the
... seems to be behaving oddly:
dllwrap -o rainbow.dll --def rainbow.def rainbow.o
c:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe:
cannot find -lpostgres
Hi all,
We need to find a solution for a strange problem.
We have a plpgsql FUNCTION which performs an heavy job (named
test_func).
CREATE or replace function test_func(z int) returns integer as $$
declare
tst integer;
begin
--
-- Large jobs with z
--
tst := nextval('test_truc');
return tst;
I am getting the following error(s) when replicating tsearch2 from v 7.4.x to v 8.1.0remoteWorkerThread_1: copy from stdin on local node - PGRES_FATAL_ERROR ERROR: function "spell_init(text)" does not [EMAIL PROTECTED] CONTEXT: COPY pg_ts_dict, line 1, column dict_init: "spell_init(text)"the
hi all,
Not sure it's the right group, but I've spent the afternoon googling and
trying on this.
In PHP (Apache Module)
I try pg_exec(COPY blah TO STDOUT WITH blah);
It runs for ever...
How can I get the output of COPY in PHP?
Copy_from is not an option because the goal is to get a CSV file.
On Wed, Dec 21, 2005 at 07:16:28PM +0100, ohp@pyrenet.fr wrote:
In PHP (Apache Module)
I try pg_exec(COPY blah TO STDOUT WITH blah);
It runs for ever...
How can I get the output of COPY in PHP?
You need to use the API functions for copy. In C they are:
PQgetCopyData
PQputCopyData
Dave Cramer [EMAIL PROTECTED] writes:
Is it possible to add the old signatures back for backward
compatibility ? Something like a tsearch2-compat lib ?
The old signatures were security holes. We are not going to put them
back. I would suggest changing the functions on the 7.4 machine to the
Trent Shipley wrote:
On Saturday 2005-12-17 16:28, Lukas Smith wrote:
Bruce Momjian wrote:
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are available
Wouldn't it also
Have you tried
SELECT *, test_func(idkeyword)
FROM (SELECT * FROM tag OFFSET 5000 LIMIT 1)
;
?
This should probably have been on -general, btw.
On Wed, Dec 21, 2005 at 06:44:33PM +0100, REYNAUD Jean-Samuel wrote:
Hi all,
We need to find a solution for a strange problem.
We have a
Andreas Pflug wrote:
Martijn van Oosterhout wrote:
So it's only an issue if you have a policy of removing old versions of
libpq on upgrades... I'm not sure what's best practice on windows in
this area.
When removing the application (in this case: pgsql), you'd remove that
old lib
On 12/21/05, Bruce Momjian pgman@candle.pha.pa.us wrote:
Andreas Pflug wrote:
Martijn van Oosterhout wrote:
So it's only an issue if you have a policy of removing old versions of
libpq on upgrades... I'm not sure what's best practice on windows in
this area.
When removing the
Hello,
I've got a problem with sorting polish words in postgresql 7.4.2
For example, I've got couple of polish cities in my table 'x', results
of sorting are:
(select city from x order by city asc)
Bydgoszcz
Gdańsk
Iława
Łódź
Żarnów
Malbork
Warszawa
So Żarnów is placed in wrong place,
On Wed, Dec 21, 2005 at 07:16:28PM +0100, ohp@pyrenet.fr wrote:
Not sure it's the right group, but I've spent the afternoon googling and
trying on this.
In PHP (Apache Module)
pgsql-php might be more appropriate, or possibly a PHP mailing list.
I try pg_exec(COPY blah TO STDOUT WITH blah);
Thanks, that might be easier than first thought.
Dave
On 21-Dec-05, at 2:04 PM, Tom Lane wrote:
Dave Cramer [EMAIL PROTECTED] writes:
Is it possible to add the old signatures back for backward
compatibility ? Something like a tsearch2-compat lib ?
The old signatures were security holes. We
Anna Domachowska [EMAIL PROTECTED] writes:
So ¯arnów is placed in wrong place, because it should be found after letter
Z ??
What's wrong? Is there any patch to fix this? Does anybody had similar
problem?
I belive that postgres was compiled with --enable-locale, and the right
locale is
Rick Gigger wrote:
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
Ühel kenal päeval, K, 2005-12-21 kell 09:50, kirjutas Hannu Krosing:
Ü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
On Wed, Dec 21, 2005 at 02:51:46PM -0500, Bruce Momjian wrote:
If you add a version number to the Win32 libpq name, you have to update
any command-line compile tools that mention libpq after an upgrade. The
Unix linker knows about version numbers, but the Win32 linker doesn't,
so adding
Anna Domachowska [EMAIL PROTECTED] writes:
I've got a problem with sorting polish words in postgresql 7.4.2
...
I belive that postgres was compiled with --enable-locale, and the
right locale is set.
How sure are you of that? This sure sounds like a wrong-locale problem
to me. Try show
When we discussed online REINDEX recently we focused on the REINDEX
command itself rather than look at alternative approaches.
One reason to REINDEX is because of index page splits getting things out
of sequence and generally bloating the index.
When we VACUUM, each index is scanned in logical
Simon Riggs [EMAIL PROTECTED] writes:
While we scan, if we found two adjacent pages, both of which have less
than (say) 40% rows, we could re-join or unsplit those pages together.
Curiously enough, this has been thought of before. It is not as easy
as you think, or it would have been done the
On Sat, 17 Dec 2005 00:03:25 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
I've still got a problem with these checks; I think they are a net
waste of cycles on average. [...]
and when they fail, those cycles are entirely wasted;
you have not advanced the state of the sort at all.
How can we make
On Wed, Dec 21, 2005 at 05:43:38PM -0500, Bruce Momjian wrote:
Rick Gigger wrote:
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
I'm not sure whether we'd need any additional planner knobs to control
this. I think that the existing join_collapse_limit GUC variable should
continue to exist, but its effect on left/right joins will be the same as
for inner joins. If anyone wants to force join order for outer joins more
than
IIRC the whole point of this exercise was to avoid passing the password
to the server in the first place. Unless you are talking about a PHP
md5() password of course ...
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will
We have encountered a very nasty but apparently rare bug which appears to
result in catalog corruption. I have not been able to pin down an exact
sequence of events which cause this problem, it appears to be a race
condition of some sort. This is what I have been able to figure out so
far.
* It
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Wed, Dec 21, 2005 at 02:51:46PM -0500, Bruce Momjian wrote:
If you add a version number to the Win32 libpq name, you have to update
any command-line compile tools that mention libpq after an upgrade. The
Unix linker knows
Now that Oracle supports i18n dependant behavior in its to_char
formatting functions (at least for its 10g release) I was wondering if
a patch to support this in PostgreSQL will get accepted. I was hoping
to work on this now that I have some spare time.
Regards,
Manuel.
Tom Lane wrote:
Well, more generally what we need is a better match algorithm in
make_relative_path. After a few moment's thought I propose:
* Determine the common prefix of the compiled-in target_path and
bin_path (for typical cases this would be /usr or /usr/local;
worst case is that the
Jeremy Drake [EMAIL PROTECTED] writes:
We have encountered a very nasty but apparently rare bug which appears to
result in catalog corruption.
How much of this can you reproduce on 8.1.1? We've fixed a few issues
already.
This was built from the gentoo ebuild version 8.1.0
I'd be even more
Manuel Sugawara masm@fciencias.unam.mx wrote
Now that Oracle supports i18n dependant behavior in its to_char
formatting functions (at least for its 10g release) I was wondering if
a patch to support this in PostgreSQL will get accepted. I was hoping
to work on this now that I have some spare
Jim C. Nasby wrote:
On Wed, Dec 21, 2005 at 05:43:38PM -0500, Bruce Momjian wrote:
Rick Gigger wrote:
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
Manuel Sugawara masm@fciencias.unam.mx writes:
Now that Oracle supports i18n dependant behavior in its to_char
formatting functions (at least for its 10g release) I was wondering if
a patch to support this in PostgreSQL will get accepted.
I thought to_char already had i18n behavior. What
Qingqing Zhou [EMAIL PROTECTED] writes:
Can you give a small introduction of i18n and what's your plan in
PostgreSQL?
i18n == Internationalization (maybe I should say l10n ==
localization). This means that to_char functions might lead to
different results depending on the i18n settings. For
Tom Lane [EMAIL PROTECTED] writes:
I thought to_char already had i18n behavior. What exactly are you
thinking of changing?
The modifiers that are suitable to localize. Month and day names comes
to mind and maybe others, I'm not sure what the state of the code is,
but I can say that, at least,
Manuel Sugawara masm@fciencias.unam.mx writes:
(Some time ago I proposed an--incomplete--patch and it was rejectd by
Karel arguing that to_char functions should behave *exactly* the same
way that they do in Oracle.)
That is the accepted plan for to_char ... of course, if Oracle changes
to_char
Manuel Sugawara masm@fciencias.unam.mx wrote
i18n == Internationalization (maybe I should say l10n ==
localization).
Good hint, I got it :-) Just like a crossword puzzle. 18 means there are 18
characters between 'i' and 'n' ...
Regards,
Qingqing
---(end of
Qingqing Zhou wrote:
Manuel Sugawara masm@fciencias.unam.mx wrote
i18n == Internationalization (maybe I should say l10n ==
localization).
Good hint, I got it :-) Just like a crossword puzzle. 18 means there are 18
characters between 'i' and 'n' ...
Huh? I don't understand.
--
Manuel Sugawara masm@fciencias.unam.mx writes:
Tom Lane [EMAIL PROTECTED] writes:
I thought to_char already had i18n behavior. What exactly are you
thinking of changing?
The modifiers that are suitable to localize. Month and day names comes
to mind and maybe others, I'm not sure what the
Tom Lane [EMAIL PROTECTED] writes:
Can we spell the names differently but keep to the same field widths?
I can see where it might cause problems to change the widths --- other
than that, no objection.
Quite impossible. But if someone is relaying in the current behavior
of to_char she might
On Wed, 21 Dec 2005, Tom Lane wrote:
Manuel Sugawara masm@fciencias.unam.mx writes:
(Some time ago I proposed an--incomplete--patch and it was rejectd by
Karel arguing that to_char functions should behave *exactly* the same
way that they do in Oracle.)
That is the accepted plan for
Gavin Sherry [EMAIL PROTECTED] writes:
There's some functionality in 10g which PostgreSQL does not have:
Good to know. I'm not an Oracle expert, actually I knew this reading
an article in a past issue of the Oracle's magazine about i18n;
essentially they were talking about how easy was for an
On Thu, Dec 22, 2005 at 01:43:34AM +0100, Manfred Koizar wrote:
Qsorting N elements costs O(N*lnN), so excluding H elements from the
sort reduces the cost by at least O(H*lnN). The merge step costs O(N)
plus some (=50%) more memory, unless someone knows a fast in-place
merge. So depending on
48 matches
Mail list logo
