Michael Shepelev <[EMAIL PROTECTED]> writes:
> I found bug (IMHO) in Insert/Select Union command.
> Result of SELECT UNION differs from INSERT SELECT UNION.
Wow, that's bizarre. I confirm seeing the inconsistent behavior.
I think it's probably got something to do with the UNION code's
manipulat
POSTGRESQL BUG REPORT TEMPLATE
Your name : Michael Shepelev
Your email address : [EMAIL PROTECTED]
"Jim Buckley" <[EMAIL PROTECTED]> writes:
> The initdb crashes with the following error:
> ERROR: pg_atoi: error in "template1": can't parse
> "template1"
Hmm, seems pretty wacko. I haven't seen that before, but I wonder
whether you are using inconsistent bits of code, ie, a mismatch of
files
Did you do an install from source? If so, I had a problem similar to
this when installing on 6.5.3 on RH6.0. The postgres install script
doesn't clean out the old binaries from /usr/bin, and setting your
path as listed in the installation instructions puts the newly created
binaries directory a
Greetings.
I have read many of the questions concerning this issue. I
too have installed PostgreSQL 6.5.3 faithfully following the
instructions in the INSTALL file. The initdb crashes with
the following error:
ERROR: pg_atoi: error in "template1": can't parse
"template1"
In my reading of the q
"James Finch" <[EMAIL PROTECTED]> writes:
> Arguments to a function seem to be incorrectly validated against constraints
> on the table on which it operates.
I think what's really going on here is that because the function manager
interface defines only one isNull flag for a function call, *all*
Made a mistake in the bug report below. Last line should read something
like:
select createAtom( 1, 'abc', 'Fred', 'NT', 'a', null );
-Original Message-
From: James Finch [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 24, 2000 4:41 PM
To: '[EMAIL PROTECTED]'
Subject: Bogus reporting of
Platform: Linux-2.2.12-20 (RH 6.1)
PostgreSQL: 7.0RC1
Description:
Arguments to a function seem to be incorrectly validated against constraints
on the table on which it operates. For example: I have a table that defines
one column (id) as a primary key, and also specifies the NOT NULL
constraint.
>> Currently, if you specify an index opclass then the system assumes that
>> you know what you are doing; there is no cross-check to see if the
>> chosen operators will work with the column datatype. That bothers me,
>> but I hesitate to insert a type-compatibility check; I wonder whether
>> the
Tom Lane wrote:
> Actually, I don't have to look very hard:
>
> CREATE TABLE td_products ( grp CHAR(2), cat CHAR(2), sub CHAR(2), vend_code
>CHAR(6), manu_part CHAR(20), part_num CHAR(15), descr CHAR(50), cost NUMERIC(10,2),
>retail NUMERIC(10,2), qty INT4, list_price NUMERIC(10,2), eff_
>> Wups, got it already. It happens on the second insert, luckily (the db is
>> HUGE :-). I've attached the offending SQL script.
> Got it, confirm seeing the crash here. I have to do real work now :-(
> but will look into it tonight.
Actually, I don't have to look very hard:
CREATE TABLE td
Frank Mayhar <[EMAIL PROTECTED]> writes:
> This probably depends heavily on the data I'm using and the script I
> wrote.
Yeah, probably so. Can you extract an SQL script that causes the
problem? That would make it possible to try to reproduce the failure
here, which would vastly simplify debugg
POSTGRESQL BUG REPORT TEMPLATE
Your name : Frank Mayhar
Your email address : [EMAIL PR
13 matches
Mail list logo
