[hs@schlittermann.de: Postg

--fdj2RfSjLxBAspz7
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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
--=20
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

--fdj2RfSjLxBAspz7
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path:
Received: from webserv ([unix socket])
by webserv (Cyrus v2.1.18-IPv6-Debian-2.1.18-1+sarge2) with LMTP; Thu, 19 Mar 2009 10:50:29 +0100
X-Sieve: CMU Sieve 2.2
Received: from amavis by webserv.wug.de with scanned-ok (Exim 3.36 #1)
id 1LkEtR-0000NF-00
for kretschmer@localhost; Thu, 19 Mar 2009 10:50:29 +0100
Received: from webserv.wug.de ([127.0.0.1])
by localhost (webserv [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 00693-08 for ;
Thu, 19 Mar 2009 10:50:07 +0100 (CET)
Received: from localhost ([127.0.0.1] ident=root)
by webserv.wug.de with esmtp (Exim 3.36 #1)
id 1LkEt5-0000Mp-01
for kretschmer@localhost; Thu, 19 Mar 2009 10:50:07 +0100
Received: from pop.1und1.com [212.227.15.177]
by localhost with POP3 (fetchmail-6.2.5)
for kretschmer@localhost (single-drop); Thu, 19 Mar 2009 10:50:07 +0100 (CET)
Received: from ssl.schlittermann.de (pu.schlittermann.de [212.80.235.130])
by mx.kundenserver.de (node=mxeu3) with ESMTP (Nemesis)
id 0MKqIe-1LkEpF1rl2-0008RC ; Thu, 19 Mar 2009 10:46:09 +0100
Received: from localhost ([127.0.0.1]:53039 helo=pu.schlittermann.de)
by ssl.schlittermann.de with esmtp (Exim 4.68)
(envelope-from )
id 1LkEpE-0006fu-Td; Thu, 19 Mar 2009 10:46:09 +0100
Received: from uucp by ssl.schlittermann.de with local-rmail (Exim 4.68)
(envelope-from ) id 1LkEot-0006eo-Ax
for lug-dd@mailman.schlittermann.de; Thu, 19 Mar 2009 10:45:47 +0100
Received: from heiko by jumper with local (Exim 4.69)
(envelope-from ) id 1LkEoJ-0004hH-6h
for Lug-dd@mailman.schlittermann.de; Thu, 19 Mar 2009 10:45:11 +0100
Date: Thu, 19 Mar 2009 10:45:11 +0100
From: Heiko Schlittermann
To: Lug-dd
Message-ID: <20090319094511.GF11937@jumper>
Mail-Followup-To: Lug-dd
MIME-Version: 1.0
X-Phone: +49.172.7909055 / SMS welcome
Organization: schlittermann -- internet & unix support
User-Agent: Mutt/1.5.18 (2008-05-17)
X-BeenThere: lug-dd@mailman.schlittermann.de
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Linux-User-Group Dresden
List-Id: Linux-User-Group Dresden
List-Unsubscribe: ,

List-Archive:
List-Post:
List-Help:
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1256415066=="
Mime-version: 1.0
Sender: lug-dd-bounces@mailman.schlittermann.de
Errors-To: lug-dd-bounces@mailman.schlittermann.de
Subject: PostgreSQL 8.1.11: pg_dump =?utf-8?Q?wei?=
=?utf-8?B?w58=?= nichts von umbenannten Indizes?
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at schollglas.com


--===============1256415066==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="11Y7aswkeuHtSBEs"
Content-Disposition: inline


--11Y7aswkeuHtSBEs
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 ...=20

psql> CREATE TABLE a1 (id BIGSERIAL PRIMARY KEY, name TEXT);
psql> \d+ a1
Column | Type | Modifiers | De=
scription=20
--------+--------+------------------------------------------ -------+---=
----------
id | bigint | not null default nextval('a1_id_seq'::regclass) |=20
name | text | |=20
Indexes:
"a1_pkey" PRIMARY KEY, btree (id)
Has OIDs: no


Wenn ich das per pg_dump ausspucke, kommt da erwartungsgemäß die=
=20
Table-Definition und dann im Dump noc hein ein=20

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 | De=
scription=20
--------+--------+------------------------------------------ -------+---=
----------
id | bigint | not null default nextval('a1_id_seq'::regclass) |=20
name | text | |=20
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=20
--=20
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann HS12-RIPE -----------------------------------------
gnupg encrypted messages are welcome - key ID: 48D0359B ---------------
gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B -

--11Y7aswkeuHtSBEs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknCFCcACgkQ7k6smEjQNZvSVgCeK3WTzZhY2zgQ3GOBPTE6 3z3H
1V0AoLmNJxt4wa6UHA6LVitMvrkjofbA
=OfTN
-----END PGP SIGNATURE-----

--11Y7aswkeuHtSBEs--



--===============1256415066==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

_______________________________________________
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd=

--===============1256415066==--




--fdj2RfSjLxBAspz7
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

--fdj2RfSjLxBAspz7--

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

A. Kretschmer wrote:
> Moin,
>=20
> ich leite hier mal was rein. Ich habe mal geschaut, was in pg_constrain=
t
> 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?
>=20
> (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=20
Constraint. Der Index wurde ja automatisch als Implementierungsdetail=20
des Constraints angelegt. Korrekt wäre also entweder das direkte=20
Umbenennen des Index zu verhindern, oder -- etwas menschenfreundlicher,=20
wie es 8.3 ja auch macht -- den Constraint mit dem Index anzugleichen.

>=20
>=20
> Andreas
>=20
>=20
> ------------------------------------------------------------ -----------=
-
>=20
> Subject:
> PostgreSQL 8.1.11: pg_dump weiß nichts von umbenannten Indizes?
> From:
> Heiko Schlittermann
> Date:
> Thu, 19 Mar 2009 10:45:11 +0100
> To:
> Lug-dd
>=20
> To:
> Lug-dd
>=20
>=20
> Hallo,
>=20
> 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 ...=20
>=20
> psql> CREATE TABLE a1 (id BIGSERIAL PRIMARY KEY, name TEXT);
> psql> \d+ a1
> Column | Type | Modifiers =
| Description=20
> --------+--------+------------------------------------------ -------=
+-------------
> id | bigint | not null default nextval('a1_id_seq'::regclass) =
|=20
> name | text | =
|=20
> Indexes:
> "a1_pkey" PRIMARY KEY, btree (id)
> Has OIDs: no
>=20
>=20
> Wenn ich das per pg_dump ausspucke, kommt da erwartungsgemäß =
die=20
> Table-Definition und dann im Dump noc hein ein=20
>=20
> ALTER TABLE ONLY a1 ADD CONSTRAINT a1_pkey PRIMARY KEY (id);
>=20
> Soweit so gut.
>=20
> Jetzt habe ich die Tabelle und auch den Index umbenannt:
>=20
> psql> ALTER TABLE a1 RENAME TO a2;
> psql> ALTER INDEX a1_pkey RENAME TO a2_pkey;
> psql> \d+ a2
> Column | Type | Modifiers =
| Description=20
> --------+--------+------------------------------------------ -------=
+-------------
> id | bigint | not null default nextval('a1_id_seq'::regclass) =
|=20
> name | text | =
|=20
> Indexes:
> "a2_pkey" PRIMARY KEY, btree (id)
> Has OIDs: no
>=20
> Sieht auch noch gut aus, Tabelle und Index haben neue Namen.
> Jetzt aber im pg_dump, erscheint immer noch
>=20
> ALTER TABLE ONLY a2 ADD CONSTRAINT a1_pkey PRIMARY KEY (id);
>=20
> Und mein a2_pkey wird nirgens erwähnt.
>=20
> 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. Exper=
iment
> auch mit dem 8.3.6 Server, dann ist es, wie ich's erwartet hätte.
>=20
>=20
> Viele Grüße
> Heiko=20
>=20
>=20
> ------------------------------------------------------------ -----------=
-
>=20
> _______________________________________________
> Lug-dd maillist - Lug-dd@mailman.schlittermann.de
> https://ssl.schlittermann.de/mailman/listinfo/lug-dd
>=20
>=20
> ------------------------------------------------------------ -----------=
-
>=20
>=20


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: [hs

--ZmZU9S7l/XJx5q9b
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Peter Eisentraut (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 =20
> Constraint. Der Index wurde ja automatisch als Implementierungsdetail =20
> des Constraints angelegt. Korrekt wäre also entweder das direkte =20
> Umbenennen des Index zu verhindern, oder -- etwas menschenfreundlicher, =
=20
> 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