Re: [pgsql-de-allgemein] Re: [pgsql-de-allgemein] [hs@schlittermann.de: PostgreSQL 8.1.11: pg_dump weiß nichts von umbenannten Indizes?]

Moin,

ich leite hier mal was rein. Ich habe mal geschaut, was in pg_constraint
und was in pg_class steht, und ich pg_constraint ist das offensichtlich
falsch, also ich würde es als Bug sehen. Was meint ihr?

(Problem nachvollzogen mit 8.1.4)

Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

A. Kretschmer wrote:
> Moin,
>
> ich leite hier mal was rein. Ich habe mal geschaut, was in pg_constraint
> und was in pg_class steht, und ich pg_constraint ist das offensichtlich
> falsch, also ich würde es als Bug sehen. Was meint ihr?
>
> (Problem nachvollzogen mit 8.1.4)

Vorneweg: in 8.3 geht es richtig.

Das Problem ist aber, dass er den Index umbenannt hat und nicht den
Constraint. Der Index wurde ja automatisch als Implementierungsdetail
des Constraints angelegt. Korrekt wäre also entweder das direkte
Umbenennen des Index zu verhindern, oder -- etwas menschenfreundlicher,
wie es 8.3 ja auch macht -- den Constraint mit dem Index anzugleichen.

>
>
> Andreas
>
>
> ------------------------------------------------------------------------
>
> Subject:
> PostgreSQL 8.1.11: pg_dump weiß nichts von umbenannten Indizes?
> From:
> Heiko Schlittermann <hs(at)schlittermann(dot)de>
> Date:
> Thu, 19 Mar 2009 10:45:11 +0100
> To:
> Lug-dd <Lug-dd(at)mailman(dot)schlittermann(dot)de>
>
> To:
> Lug-dd <Lug-dd(at)mailman(dot)schlittermann(dot)de>
>
>
> Hallo,
>
> es gibt ja hier den einen oder anderen, der PostgreSQL macht.
> Ich habe da etwas, was ich für komisch halte. Es handelt sich um 8.1.11
> als Server - ist nicht mehr das Neueste, ich weiß, aber es ist ein SLES
> und da muß es super sein ...
>
> psql> CREATE TABLE a1 (id BIGSERIAL PRIMARY KEY, name TEXT);
> psql> \d+ a1
> Column | Type | Modifiers | Description
> --------+--------+-------------------------------------------------+-------------
> id | bigint | not null default nextval('a1_id_seq'::regclass) |
> name | text | |
> Indexes:
> "a1_pkey" PRIMARY KEY, btree (id)
> Has OIDs: no
>
>
> Wenn ich das per pg_dump ausspucke, kommt da erwartungsgemäß die
> Table-Definition und dann im Dump noc hein ein
>
> ALTER TABLE ONLY a1 ADD CONSTRAINT a1_pkey PRIMARY KEY (id);
>
> Soweit so gut.
>
> Jetzt habe ich die Tabelle und auch den Index umbenannt:
>
> psql> ALTER TABLE a1 RENAME TO a2;
> psql> ALTER INDEX a1_pkey RENAME TO a2_pkey;
> psql> \d+ a2
> Column | Type | Modifiers | Description
> --------+--------+-------------------------------------------------+-------------
> id | bigint | not null default nextval('a1_id_seq'::regclass) |
> name | text | |
> Indexes:
> "a2_pkey" PRIMARY KEY, btree (id)
> Has OIDs: no
>
> Sieht auch noch gut aus, Tabelle und Index haben neue Namen.
> Jetzt aber im pg_dump, erscheint immer noch
>
> ALTER TABLE ONLY a2 ADD CONSTRAINT a1_pkey PRIMARY KEY (id);
>
> Und mein a2_pkey wird nirgens erwähnt.
>
> Bug oder Feature? Oder mache ich etwas falsch? Am "pg_dump" scheint es
> nicht zu liegen, wenn ich auf einer anderen Maschine ein pg_dump (8.3.6)
> nehme, dann ist das genauso falsch, außer ich mache das o.a. Experiment
> auch mit dem 8.3.6 Server, dann ist es, wie ich's erwartet hätte.
>
>
> Viele Grüße
> Heiko
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Lug-dd maillist - Lug-dd(at)mailman(dot)schlittermann(dot)de
> https://ssl.schlittermann.de/mailman/listinfo/lug-dd
>
>
> ------------------------------------------------------------------------
>
>

Peter Eisentraut <peter_e(at)gmx(dot)net> (Do 19 Mär 2009 13:45:38 CET):
> A. Kretschmer wrote:
>> Moin,
>>
>> ich leite hier mal was rein. Ich habe mal geschaut, was in pg_constraint
>> und was in pg_class steht, und ich pg_constraint ist das offensichtlich
>> falsch, also ich würde es als Bug sehen. Was meint ihr?
>>
>> (Problem nachvollzogen mit 8.1.4)
>
> Vorneweg: in 8.3 geht es richtig.
>
> Das Problem ist aber, dass er den Index umbenannt hat und nicht den
> Constraint. Der Index wurde ja automatisch als Implementierungsdetail
> des Constraints angelegt. Korrekt wäre also entweder das direkte
> Umbenennen des Index zu verhindern, oder -- etwas menschenfreundlicher,
> wie es 8.3 ja auch macht -- den Constraint mit dem Index anzugleichen.
>

Da ein "ALTER CONSTRAINT xyz RENAME TO abc" nicht existiert (?), wäre
der offizielle Weg ein "ALTER TABLE <table> DROP CONSTRAINT xyz" und dann
ein "ALTER TABLE <table> ADD <table_constraint>" ?

--
Heiko

Heiko Schlittermann <hs(at)schlittermann(dot)de> wrote:

> Peter Eisentraut <peter_e(at)gmx(dot)net> (Do 19 Mär 2009 13:45:38 CET):
> >
> > Vorneweg: in 8.3 geht es richtig.
> >
> > Das Problem ist aber, dass er den Index umbenannt hat und nicht den
> > Constraint. Der Index wurde ja automatisch als Implementierungsdetail
> > des Constraints angelegt. Korrekt wäre also entweder das direkte
> > Umbenennen des Index zu verhindern, oder -- etwas menschenfreundlicher,
> > wie es 8.3 ja auch macht -- den Constraint mit dem Index anzugleichen.
> >
>
> Da ein "ALTER CONSTRAINT xyz RENAME TO abc" nicht existiert (?), wäre
> der offizielle Weg ein "ALTER TABLE <table> DROP CONSTRAINT xyz" und dann
> ein "ALTER TABLE <table> ADD <table_constraint>" ?

Jo. Und alles schön in einer Transaktion, denn PG kann auch DDL
innerhalb einer Transaktion...

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

Andreas Kretschmer wrote:
> Heiko Schlittermann <hs(at)schlittermann(dot)de> wrote:
>
>> Peter Eisentraut <peter_e(at)gmx(dot)net> (Do 19 Mär 2009 13:45:38 CET):
>>> Vorneweg: in 8.3 geht es richtig.
>>>
>>> Das Problem ist aber, dass er den Index umbenannt hat und nicht den
>>> Constraint. Der Index wurde ja automatisch als Implementierungsdetail
>>> des Constraints angelegt. Korrekt wäre also entweder das direkte
>>> Umbenennen des Index zu verhindern, oder -- etwas menschenfreundlicher,
>>> wie es 8.3 ja auch macht -- den Constraint mit dem Index anzugleichen.
>>>
>> Da ein "ALTER CONSTRAINT xyz RENAME TO abc" nicht existiert (?), wäre
>> der offizielle Weg ein "ALTER TABLE <table> DROP CONSTRAINT xyz" und dann
>> ein "ALTER TABLE <table> ADD <table_constraint>" ?
>
> Jo. Und alles schön in einer Transaktion, denn PG kann auch DDL
> innerhalb einer Transaktion...

Das geht zwar, ist aber nicht der Performance-Knaller. Die Möglichkeit,
das direkt umzubennen, wäre schon schöner.

Peter Eisentraut wrote:
>>> Da ein "ALTER CONSTRAINT xyz RENAME TO abc" nicht existiert (?), wäre
>>> der offizielle Weg ein "ALTER TABLE <table> DROP CONSTRAINT xyz" und
>>> dann
>>> ein "ALTER TABLE <table> ADD <table_constraint>" ?
>>
>> Jo. Und alles schön in einer Transaktion, denn PG kann auch DDL
>> innerhalb einer Transaktion...
>
> Das geht zwar, ist aber nicht der Performance-Knaller. Die Möglichkeit,
> das direkt umzubennen, wäre schon schöner.

Stand auch schon in der TODO-Liste.

Andreas Kretschmer schrieb:
> ich leite hier mal was rein. Ich habe mal geschaut, was in pg_constraint
> und was in pg_class steht, und ich pg_constraint ist das offensichtlich
> falsch, also ich würde es als Bug sehen. Was meint ihr?
>
> (Problem nachvollzogen mit 8.1.4)

Das Problem tritt auch in 8.2.13 auf, nicht aber in 8.3.5.

Es handelt sich wohl um Bug #3854, behoben hier:
http://archives.postgresql.org/pgsql-committers/2008-01/msg00241.php

Vielleicht ein gutes Argument, auf 8.3 zu gehen, Suse hin, Suse her.

Liebe Grüße,
Laurenz Albe