Malcolm Tredinnick <[EMAIL PROTECTED]> writes:
> So given that one cannot just insert 0 into a bigint field (even an
> array of bigints), since postgres complains it is not of the correct
> type, how is one supposed to fille a field of bigint[] with {0, 0}?
I must be missing something ... what is
[EMAIL PROTECTED] writes:
> cast() no longer works in array inserts
It never has. You are confusing a rather lame failure of error checking
in 7.1 with a feature. 7.1 and before will in fact take quite a lot of
random garbage in array input strings :=(
regards, tom lane
Malcolm Tredinnick ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
cast() no longer works in array inserts
Long Description
If I have a table containing an array (e.g. a bigint[] field), then it does not appear
to be possible t
=?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?=
<[EMAIL PROTECTED]> writes:
> I installed an newer rpm of the glibc (2.2.2-8.1 / 2.2.2-4 before) und
> reinitialized the database with locale=3DC.
> Just after installing the rpm, the problem was still there (reindex I =
> did),
> but after
Title: AW: AW: [BUGS] strange problem
Hi,
I installed an newer rpm of the glibc (2.2.2-8.1 / 2.2.2-4 before) und reinitialized the database with locale=C.
Just after installing the rpm, the problem was still there (reindex I did), but after dump/initdb --locale=C/import the problem was g
=?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?=
<[EMAIL PROTECTED]> writes:
> This happend to 0.3% of all rows in this table, after dump/import exactly
> the same rows were affected.
So you can reproduce the problem after dumping/reloading? If you could
send me the dump file (off-list!)
Title: AW: [BUGS] strange problem
Hi,
I did reindex, vacuum , dump/import, ...
I also tried 7.3.1
-->> It happens only with btree index on that column, without index it works, with hash index also no problem.
This happend to 0.3% of all rows in this table, after dump/import exactly the
=?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?=
<[EMAIL PROTECTED]> writes:
> ici=3D# select id,pseudonym from user_all where pseudonym =3D
> 'autologin_funkey';
> id | pseudonym
> +---
> (0 rows)
> ici=3D# select id,pseudonym from user_all where pseudonym ~
> '^autologin_fun
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> ERROR: copy: line 1, Bad timestamp external representation '11/31/02'
> lost synchronization with server, resetting connection
This is not a backend crash, this is libpq's standard operating
procedure for recovering from an error during COPY.
If we h
On Wed, Dec 18, 2002 at 09:14:18 -0600,
Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> It looks like when a bad date is entered using COPY the backend connection
> gets killed.
I just tried it with 7.3.1 and get the same error.
---(end of broadcast)
Title: strange problem
Hi,
I don't know what is going on here. Maybe somebody can help.
Iam using postgresql 7.3.
ici=# select id,pseudonym from user_all where pseudonym = 'autologin_funkey';
id | pseudonym
+---
(0 rows)
ici=# select id,pseudonym from user_all where pseud
It looks like when a bad date is entered using COPY the backend connection
gets killed.
I noticed this when having a problem loading a database with several copies
in one transaction. The backend died consistantly at the same point, but
not near where the bad dates were. I eventually found the bad
12 matches
Mail list logo
