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 dependin
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 Wed, 21 Dec 2005, Tom Lane wrote:
> Manuel Sugawara 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 cour
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 migh
Manuel Sugawara 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 state of the cod
Qingqing Zhou wrote:
>
> "Manuel Sugawara" 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.
--
Bruce Momji
"Manuel Sugawara" 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 broadcast)--
Manuel Sugawara 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 every so often, it'
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 lea
"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. F
Manuel Sugawara 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 exactly are you
thinking
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
"Manuel Sugawara" 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 time.
>
Can you
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 m
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
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.
-
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 kno
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
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 ig
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
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
> >
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 ma
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
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 or
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 "s
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 ve
Ü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 t
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 an
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
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. W
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 bl
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, becau
On 12/21/05, Bruce Momjian 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
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 th
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
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
> >
> > Wo
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
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
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
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 prob
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;
e
... 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
s
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
"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 cod
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
>> knowledg
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 th
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 ne
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 softwa
48 matches
Mail list logo