-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El 13/05/13 17:06, Tom Lane escribió:
> hcu...@exa.unicen.edu.ar writes:
>> PostgreSQL version: 8.4.17
>
>> After statments triggers on child tables are sometimes executed and
>> sometimes are not. As I far as I could see, when the after trigger is
>>
On Sunday, May 12, 2013 9:40 PM Chaya Gilburt wrote:
> Dear Sirs,
> We are observing an odd phenomena with PostgresSQL, which is no doubt due
to our using the database improperly. That database in question is
PostgresSQL Version 8.7.1 and runs on a machine installed
> with Server 2003. The DELET
The following bug has been logged on the website:
Bug reference: 8156
Logged by: Regina
Email address: l...@pcorp.us
PostgreSQL version: 9.2.4
Operating system: Windows 7 64-bit compiled with visual c++ - EDB 64
Description:
Nothing to do yet unless its obvious to you
hcu...@exa.unicen.edu.ar writes:
> PostgreSQL version: 8.4.17
> After statments triggers on child tables are sometimes executed and
> sometimes are not. As I far as I could see, when the after trigger is
> defined in only one of the tables it may not get executed, wether when it is
> defined in ev
On 5/12/2013 9:10 AM, Chaya Gilburt wrote:
PostgresSQL Version 8.7.1
hopefully, you mean 8.1.7 ? there never was a 8.7 release, it went up
to 8.4 then rolled over to 9.0
--
john r pierce 37N 122W
somewhere on the middle of the left coast
--
Sent via
The following bug has been logged on the website:
Bug reference: 8152
Logged by: Hugo J. Curti
Email address: hcu...@exa.unicen.edu.ar
PostgreSQL version: 8.4.17
Operating system: Debian GNU/Linux 6.0.7 (squeeze)
Description:
I don't know if this is really a bug, but
Dear Sirs,
We are observing an odd phenomena with PostgresSQL, which is no doubt due to
our using the database improperly. That database in question is PostgresSQL
Version 8.7.1 and runs on a machine installed with Server 2003. The DELETE
commands were being issued both from a Windows XP using
The following bug has been logged on the website:
Bug reference: 8151
Logged by: Philip A Reimer
Email address: antrei...@gmail.com
PostgreSQL version: 9.2.4
Operating system: mingw-w64
Description:
I'm getting this error when running psql compiled with gcc 4.8 but do
oh, silly me.
I was making a dump of a PostgreSQL 8.4.17 backend with pg_dump
(PostgreSQL) 9.1.9
On Mon, May 13, 2013 at 4:24 PM, Tom Lane wrote:
> willy...@gmail.com writes:
> > pg_dump (PostgreSQL) 9.1.9 ends in an error when backing up my db, which
> > contains a field called "new".
>
> Wor
On 13.05.2013 17:09, Tom Lane wrote:
Heikki Linnakangas writes:
Would it be possible to be lenient, and also accept . as the decimal
separator, when there is no ambiguity? Ie. when . is not the thousands
separator.
I originally coded it that way, but concluded that it was probably a
waste of
willy...@gmail.com writes:
> pg_dump (PostgreSQL) 9.1.9 ends in an error when backing up my db, which
> contains a field called "new".
Works for me:
regression=# create table new (f1 text, new text);
CREATE TABLE
regression=# insert into new (f1, new) values ('1','2');
INSERT 0 1
regression=# cop
Heikki Linnakangas writes:
> Would it be possible to be lenient, and also accept . as the decimal
> separator, when there is no ambiguity? Ie. when . is not the thousands
> separator.
I originally coded it that way, but concluded that it was probably a
waste of code space. How many locales can
The following bug has been logged on the website:
Bug reference: 8154
Logged by: Willy-Bas Loos
Email address: willy...@gmail.com
PostgreSQL version: 9.1.9
Operating system: ubuntu 12.04 server
Description:
pg_dump (PostgreSQL) 9.1.9 ends in an error when backing up m
The following bug has been logged on the website:
Bug reference: 8153
Logged by: Marc Mamin
Email address: m...@intershop.de
PostgreSQL version: 9.2.4
Operating system: Linux & windows
Description:
hello,
This is not a functional bugs, but it appers (at least for me.
On 11.05.2013 01:17, Euler Taveira wrote:
On 10-05-2013 13:09, Thomas Kellerer wrote:
Tom Lane wrote on 10.05.2013 17:49:
I looked into this, and find that the reason it misbehaves is that
NUM_numpart_from_char() will treat a '.' as being a decimal point
*without any regard to locale considerat
15 matches
Mail list logo