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)
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
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?
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,
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 ad
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 a
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=loris&dt=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 wa
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We have a build failure to fix first:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=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 prob
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,
an
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
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?
We
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 ---
Martijn van Oosterhout 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 collation
> s
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??
>
>
"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
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
not
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 thin
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: pgsql
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 s
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 t
"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 avoi
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
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 funct
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
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
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
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.
> How wo
27 matches
Mail list logo