X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 326998B9EBE for ; Thu, 3 Feb 2005 19:47:50 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 81226-06 for ; Thu, 3 Feb 2005 19:47:46 +0000 (GMT) Received: from hosting.commandprompt.com (128.commandprompt.com [207.173.200.128]) by svr1.postgresql.org (Postfix) with ESMTP id 2F1D38B9F1A for ; Thu, 3 Feb 2005 19:47:46 +0000 (GMT) Received: from [192.168.1.51] (fc1smp [66.93.38.87]) (authenticated bits=0) by hosting.commandprompt.com (8.12.8/8.12.8) with ESMTP id j13JlS8p021987; Thu, 3 Feb 2005 11:47:28 -0800 Message-ID: <42027FC6.9020501@commandprompt.com> Date: Thu, 03 Feb 2005 11:47:18 -0800 From: "Joshua D. Drake" Organization: Command Prompt, Inc. User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: Christopher Kings-Lynne , Alvaro Herrera , pgsql-hackers@postgresql.org Subject: Re: pg_dump bug in 7.3.9 with sequences References: <42013187.7040806@commandprompt.com> <6686.1107379308@sss.pgh.pa.us> <42014C28.1070300@commandprompt.com> <20050202220404.GC1967@dcc.uchile.cl> <42016727.3020107@commandprompt.com> <11680.1107406182@sss.pgh.pa.us> <4201EE8D.4010408@familyhealth.com.au> <17154.1107451356@sss.pgh.pa.us> In-Reply-To: <17154.1107451356@sss.pgh.pa.us> Content-Type: multipart/mixed; boundary="------------000408070905000507080805" X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.043 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200502/147 X-Sequence-Number: 63975 This is a multi-part message in MIME format. --------------000408070905000507080805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tom Lane wrote: > Christopher Kings-Lynne writes: > >>>pg_dump will just emit "create table t1 (f1 serial)" with no hint that >>>the sequence ought to be set to CYCLE mode. I'm not sure about an >>>appropriate fix offhand --- we can't very well use ALTER SEQUENCE in >>>just this way in the dump, because of the risk of the sequence name >>>being possibly different at reload. (Come to think of it, we are not >>>very good about propagating GRANTs on the sequence either, because of >>>the same risk.) > > >>I suggest some time ago an alternative syntax for ALTER SEQUENCE. > > > Could work, but we'd have to support it for GRANT/REVOKE too, which is > starting to get ugly. (Now, if we went down the recently suggested path > of allowing sub-selects to compute the target object names for all > utility statements, this would fall out nicely. But having a special > case in ALTER SEQUENCE and GRANT seems pretty wart-ish.) > > Another alternative I was thinking about in the shower this morning is > to have pg_dump treat the sequence as an independent object. So the > dump script would CREATE it, set parameters and GRANTs, just the same as > for a plain sequence, and then do a magic ALTER TABLE command that > attaches it to the serial column, which the script would initially > declare as a plain integer or bigint. This seems relatively clean to me > because it is in the same spirit as the way we handle index constraints > now: they aren't in the initial table definition but get added by ALTER > at a suitable time. However the "magic command" is a big wart of its > own, no doubt. It's not just an ALTER COLUMN TYPE command because you'd > need to be able to specify the name of the sequence to attach. It's not > just an ALTER SET DEFAULT, either, because it would have special > side-effects on pg_depend. Wouldn't a lot of this be solved (I know I am over simplyfing) by making serial a real type? E.g; if you have type serial it is type serial not type integer with a default of nextval('sequence'). Thus if I have an integer with a default of (anything really) that is how it is restore. If I have a serial, it is a serial and is restored in that manner. Using this idea, you would get the can't alter default of a serial but also the ability to alter the default if it is NOT a serial but will still auto-increment. Sincerely, Joshua D. Drake > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- Command Prompt, Inc., your source for PostgreSQL replication, professional support, programming, managed services, shared and dedicated hosting. Home of the Open Source Projects plPHP, plPerlNG, pgManage, and pgPHPtoolkit. Contact us now at: +1-503-667-4564 - http://www.commandprompt.com --------------000408070905000507080805 Content-Type: text/x-vcard; charset=utf-8; name="jd.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jd.vcf" begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:jd@commandprompt.com title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard --------------000408070905000507080805--