POSTGRESQL BUG REPORT TEMPLATE
Your name : Frank Mayhar
Your email address : [EMAIL PR
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
>> 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
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_
>> 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
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.
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
"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*
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
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
"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
POSTGRESQL BUG REPORT TEMPLATE
Your name : Michael Shepelev
Your email address : [EMAIL PROTECTED]
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
13 matches
Mail list logo
