X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 6A9D3D1B55F; Wed, 29 Oct 2003 15:37:35 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 45729-02; Wed, 29 Oct 2003 11:37:08 -0400 (AST) Received: from ucsns.ucs.co.za (ucs.co.za [196.23.43.2]) by svr1.postgresql.org (Postfix) with ESMTP id 5E220D1B549; Wed, 29 Oct 2003 11:37:01 -0400 (AST) Received: from localhost (localhost.localdomain [127.0.0.1]) by ucsns.ucs.co.za (Postfix) with ESMTP id ED95E2BD89; Wed, 29 Oct 2003 17:37:00 +0200 (SAST) Received: from ucsns.ucs.co.za ([127.0.0.1]) by localhost (ucsns.ucs.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15601-05; Wed, 29 Oct 2003 17:36:59 +0200 (SAST) Received: from ucspost.ucs.co.za (mailgw1.ucs.co.za [196.23.43.253]) by ucsns.ucs.co.za (Postfix) with ESMTP id EAC472BD57; Wed, 29 Oct 2003 17:36:59 +0200 (SAST) Received: from jhb.ucs.co.za (jhb.ucs.co.za [172.31.1.3]) by ucspost.ucs.co.za (Postfix) with ESMTP id 7B084D9EA0; Wed, 29 Oct 2003 17:36:59 +0200 (SAST) Received: from svb.ucs.co.za (svb.ucs.co.za [172.31.1.148]) by jhb.ucs.co.za (Postfix) with SMTP id A87D7976E3; Wed, 29 Oct 2003 17:36:53 +0200 (SAST) Date: Wed, 29 Oct 2003 17:36:53 +0200 From: Stef To: Tom Lane Cc: Rod Taylor , pgsql-admin@postgresql.org, pgsql-sql@postgresql.org Subject: Re: [SQL] Table versions Message-Id: <20031029173653.522c804a.svb@ucs.co.za> In-Reply-To: <3731.1067437850@sss.pgh.pa.us> References: <20031029125752.35069e3b.svb@ucs.co.za> <1067435458.99917.34.camel@jester> <3731.1067437850@sss.pgh.pa.us> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) User-Agent: sillypheed-claws (anti-aliased) X-Face: LV^-*d3kQlL,6{Y:X)M~tuL#y!p.kO_Qbc!xxqhZC4s}Y]L0g)z^aiLsQGY34d|}Xp:HNm)MRsc?^?ZQ}smznF&jx|w@,a**K&QL.Dc~2~M5V`zb>hExCJDB[[o=M)e"; k-n[7tz2TY7+; *_xX's(5cUEtdw*yG-OmKm}6($zpUz8S`Nz@w X-Operating-System: sid X-X-X: _-^-_ Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Wed__29_Oct_2003_17_36_53_+0200_sr9mojtohM78H8KV" X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200310/349 X-Sequence-Number: 10910 --Signature=_Wed__29_Oct_2003_17_36_53_+0200_sr9mojtohM78H8KV Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Thanks guys, I had a feeling this was the case, but wasn't sure. The one-version pg_dump looks like a winner. Regards Stefan ##START## => Rod Taylor writes: => >> What I did next, is put a trigger on pg_attribute that should, in theory, => >> on insert and update, fire up a function that will increment a version => => > System tables do not use the same process for row insertion / updates as => > the rest of the system. You're trigger will rarely be fired. => => s/rarely/never/. We do not support triggers on system catalogs. The => system should have done its best to prevent you from creating one ... => I suppose you had to hack around with a "postgres -O" standalone backend? => => Returning to the original problem, it seems to me that comparing "pg_dump => -s" output is a reasonable way to proceed. The problem of inconsistent => output format across pg_dump versions is a red herring --- just use a => single pg_dump version (the one for your newest server) for all the => dumps. Recent pg_dump versions still talk to older servers, back to 7.0 => or thereabouts. => => regards, tom lane => --Signature=_Wed__29_Oct_2003_17_36_53_+0200_sr9mojtohM78H8KV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/n96bgDYs3UkRjZkRAuwmAKCcybHQr/Cfh1AoqU8VaTrL9+jwRgCff3l+ 0ehnKZqbdeThRvOPMiNMm0k= =yq/Z -----END PGP SIGNATURE----- --Signature=_Wed__29_Oct_2003_17_36_53_+0200_sr9mojtohM78H8KV--