On Wed, Dec 28, 2005 at 12:47:31AM +0200, Hannu Krosing wrote:
I've thought of one other possibility, which is kind of at the extreme
end of system implementation. Given the suggestion about not losing a
whole table on unclean shutdown, how about using a single table, split.
snip
How
Tom Lane wrote:
I wrote:
Michael Paesold [EMAIL PROTECTED] writes:
I am seeing a similar unique index bug here...
This is PostgreSQL 8.1.1 on RHEL 3, Intel Xeon (i686).
It looks like the problem is that index entries are being inserted out
of order.
After further investigation, it seems
Code from perl cookbook, wrapped in plperlu wrapper
not very portable, Net::SMTP would probably be better, and result in more
portable perl code.
Didn't test this - but it is copied straight from perl cookbook via
google: http://www.unix.org.ua/orelly/perl/cookbook/ch18_04.htm
CREATE OR REPLACE
Michael Paesold [EMAIL PROTECTED] writes:
This is a theory. The whole database was loaded using pg_restore, I still
have the original dump so I will have a look at the dump now. The database
actually contains some plperl functions.
OK, I think I have reproduced the problem. initdb in C
I wrote:
So the mere act of defining a plperl function, even with
check_function_bodies = false, is sufficient to send control through
that bit of libperl code that does setlocale(LC_ALL, ). Ugh.
This is much worse than I thought.
It seems one ingredient in this is that the plperl function
Tom Lane said:
I wrote:
So the mere act of defining a plperl function, even with
check_function_bodies = false, is sufficient to send control through
that bit of libperl code that does setlocale(LC_ALL, ). Ugh.
This is much worse than I thought.
It seems one ingredient in this is that the
Andrew Dunstan [EMAIL PROTECTED] writes:
It should certainly be fixed, but surely at best this would only delay
seeing the ugly locale effect - as soon as you call a perl function you'll
be back in the same boat regardless.
Right, I was not suggesting that fixing the validator would avoid the
Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] writes:
It should certainly be fixed, but surely at best this would only delay
seeing the ugly locale effect - as soon as you call a perl function
you'll be back in the same boat regardless.
Right, I was not suggesting that fixing the validator
On Mon, Dec 26, 2005 at 15:12:48 -0500,
Gregory Maxwell [EMAIL PROTECTED] wrote:
On 12/26/05, Pavel Stehule [EMAIL PROTECTED] wrote:
(1,1) * (1,2) = true
(1,2) * (2,1) is NULL
(2,3) * (1,2) = false
it's usefull for multicriterial optimalisation
This is indeed a sane and useful
Does the regression test need to be updated as well for this?
I am seeing a failure on my buildfarm machines.
-rocco
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bruce Momjian
Sent: Wednesday, December 28, 2005 11:47 AM
To:
Hi,
While trying to initdb using cvs tip, it dumps below error output:
...
creating configuration files ... ok
creating template1 database in pgd/base/1 ...
FATAL: failed to initialize TimeZone to UNKNOWN
child process exited with exit code 1
...
I edited some files but don't think
Greetings everybody,
As part of the changes I would like relating to collations, the two
sort options in inlineApplySortFunction() using only a less-than
operator may become unsupportable. This has been indirectly discussed
before [1] and no-one seemed to have an issue with it then. Internally
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
(see recent discussion).
I've committed a proposed change in HEAD --- would you check out the
Dear Michele.
Italian is no longer maintained and is long.
Please contribute. We are welcome always.:-)
http://www.pgadmin.org/translation.php
Regards,
Hiroshi Saito
From: Michele Pigozzo
I'd like to contribute to localize the application to italian language.
Do you want my help??
I
Martijn van Oosterhout kleptog@svana.org writes:
The issue is whether anything you want to ORDER BY needs to be
described by an B-tree operator class, and hence have a real sort
function.
1. Do people have any problems with this?
2. Would a patch for this be accepted seperate from the whole
Tom Lane wrote:
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
(see recent discussion).
I've committed a proposed change in HEAD ---
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've committed a proposed change in HEAD --- would you check out the
Windows behavior at your convenience? If it seems to work, I'll
back-patch, but let's test first.
Will try. Not quite sure how, though. Any suggestions?
Well, one
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've committed a proposed change in HEAD --- would you check out the
Windows behavior at your convenience? If it seems to work, I'll
back-patch, but let's test first.
Will try. Not quite sure how,
Having read through this thread, I would like to propose a
syntax/behavior.
I think we all now agree that the logging is more part of the table than
the command itself. Right now we have a COPY LOCK patch, but people are
going to want to control logging for INSERT INTO ... SELECT, and UPDATE,
Andrew Dunstan [EMAIL PROTECTED] writes:
We have a build failure to fix first:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lorisdt=2005-12-29%2000:44:52
Weird. It seems to be choking on linking to check_function_bodies,
but plpgsql does that exactly the same way, and there's no problem
Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] writes:
We have a build failure to fix first:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lorisdt=2005-12-29%2000:44:52
Weird. It seems to be choking on linking to check_function_bodies, but
plpgsql does that exactly the same way, and
now agree that the logging is more part of the table than
the command itself. Right now we have a COPY LOCK patch, but people are
going to want to control logging for INSERT INTO ... SELECT, and UPDATE,
and all sorts of other things, so I think we are best adding an ALTER
TABLE capability. I
Joshua D. Drake wrote:
now agree that the logging is more part of the table than
the command itself. Right now we have a COPY LOCK patch, but people are
going to want to control logging for INSERT INTO ... SELECT, and UPDATE,
and all sorts of other things, so I think we are best adding
On Wed, Dec 28, 2005 at 08:52:41AM +0530, Aftab Alam wrote:
Hi there,
How can i send mail form postgresql.
Generally, it is a better idea either to poll your PostgreSQL database
and send mail based on that, or use LISTEN/NOTIFY, rather than
directly sending mail from your database.
Cheers,
D
Christopher Kings-Lynne wrote:
I hope you mean 'redundant with PRIMARY KEY in example'...
Why? SERIAL implies NOT NULL (although PRIMARY KEY does as well, of course).
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Why? SERIAL implies NOT NULL (although PRIMARY KEY does as well, of
course).
Ah yes you're right. I mixed up with the fact that SERIAL no longer
implies UNIQUE...
Chris
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Wed, 2005-12-28 at 11:05 -0500, Tom Lane wrote:
Dmitry Panov [EMAIL PROTECTED] writes:
Yes, but if the server has crashed earlier the script won't be called
and if the filesystem can't be recovered the changes will be lost. My
point is the server should write into both (or more) files at
27 matches
Mail list logo
