Title: Re: [BUGS] Table constraint ordering disrupted by pg_dump
I have loaded this new version and re-tested but don't see it fixed.
If the standard regression tests are run and after completion a pg_dump
is performed: pg_dump -o regression > dumpfile, if you look in the
dumpfile,
At 17:51 3/04/01 -0400, Tom Lane wrote:
>
>Rather than using "c.rcname = pg_relcheck.rcname" as part of the match
>condition, consider
...
>it seems to me that lines 2071-2121 in pg_dump.c are largely
>a waste of time
Done and applied.
---
Philip Warner <[EMAIL PROTECTED]> writes:
> At 17:51 3/04/01 -0400, Tom Lane wrote:
>> Rather than using "c.rcname = pg_relcheck.rcname" as part of the match
>> condition, consider
>> (c.rcname = pg_relcheck.rcname OR
>> (c.rcname[0] = '$' AND pg_relcheck.rcname[0] = '$'))
>> so that any two namel
At 17:51 3/04/01 -0400, Tom Lane wrote:
>
>Rather than using "c.rcname = pg_relcheck.rcname" as part of the match
>condition, consider
> (c.rcname = pg_relcheck.rcname OR
>(c.rcname[0] = '$' AND pg_relcheck.rcname[0] = '$'))
>so that any two nameless constraints will be considered du
Patricia Holben <[EMAIL PROTECTED]> writes:
> improvement but as usual there is a related error. In the constraints=20
> test, there is a table created "INSERT_CHILD" which has a constraint and=
> then inherits from "INSERT_TBL" the constraint "insert_con" and the=20
> unnamed check. If you look
Patricia Holben <[EMAIL PROTECTED]> writes:
> I have loaded this new version and re-tested but don't see it fixed.
It looks fixed to me. Original SQL in constraints.sql:
CREATE TABLE INSERT_TBL (x INT DEFAULT nextval('insert_seq'),
y TEXT DEFAULT '-NULL-',
z INT DEFAULT -1 * cur
At 23:55 2/04/01 -0400, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> While it't not a bug, it would be nice if pg_dump reproduced definitions as
>> faithfully as possible. To that end, would it be worth selecting the
>> constraints in OID order (using oid from pg_relcheck)?
>
>If
Philip Warner <[EMAIL PROTECTED]> writes:
> While it't not a bug, it would be nice if pg_dump reproduced definitions as
> faithfully as possible. To that end, would it be worth selecting the
> constraints in OID order (using oid from pg_relcheck)?
If it's just another clause in a query, you might
At 16:40 2/04/01 -0400, Tom Lane wrote:
>
>I don't believe this is a bug. There is no guarantee that constraints
>are checked in any particular order.
>
While it't not a bug, it would be nice if pg_dump reproduced definitions as
faithfully as possible. To that end, would it be worth selecting th
[EMAIL PROTECTED] writes:
> When running a backup/restore version of the regression tests on 7.0.3
> and 7.1RCD1 the following was noted: when the create table command
> contained two constraints, the error messages would reflect that the
> constraints were being checked in a consistent order and
Tricia Holben ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Table constraint ordering disrupted by pg_dump
Long Description
When running a backup/restore version of the regression tests on 7.0.3 and 7.1RCD1 the
following was
11 matches
Mail list logo
