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 465A3D1B44D for ; Thu, 1 Jul 2004 14:04:50 -0300 (ADT) 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 45062-08 for ; Thu, 1 Jul 2004 17:04:47 +0000 (GMT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id C8136D1B27C for ; Thu, 1 Jul 2004 14:04:46 -0300 (ADT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id DBD5A35095; Thu, 1 Jul 2004 10:04:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id DA12435093; Thu, 1 Jul 2004 10:04:33 -0700 (PDT) Date: Thu, 1 Jul 2004 10:04:33 -0700 (PDT) From: Stephan Szabo To: jearl@bullysports.com Cc: Andreas Pflug , Justin Clift , Tom Lane , PostgreSQL Hackers Mailing List Subject: Re: Adding column comment to information_schema.columns In-Reply-To: Message-ID: <20040701095654.X31438@megazone.bigpanda.com> References: <40E37E3F.2050400@telstra.net> <22066.1088656403@sss.pgh.pa.us> <40E3949F.6020201@telstra.net> <40E3BB25.4020804@pse-consulting.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200407/34 X-Sequence-Number: 55595 On Thu, 1 Jul 2004 jearl@bullysports.com wrote: > Andreas Pflug writes: > > > Justin Clift wrote: > > > >> Tom Lane wrote: > >> > >>> > >>> This question has been touched on before, but I guess it's time to > >>> face it fair and square: is it reasonable for an SQL > >>> implementation to add implementation-specific columns to an > >>> information_schema view? One could certainly argue that the > >>> entire point of information_schema is to be *standard*, not more, > >>> not less. OTOH I do not know if adding an extra column is likely > >>> to break anyone's application. Comments? > >> > >> > >> Well, I suppose it reduces application portability if anyone starts > >> relying on it. > > > > > > We're advertising to do pure ANSI, so we'd mislead people if we > > supplied non-standard columns. > > Yes, but if folks wanted to stick to the standard PostgreSQL would > still work. The only difference is that people who aren't concerned That might not be true. It is possible to write queries that might work on a database without extra columns and would fail or act differently with extra columns depending on things like the names of the added columns (possibly altering natural join), the positions of the column (possibly altering sql92 order by ordinal position behavior) and the existance of the column itself (possibly altering queries that use select * on one branch of a union/intersect/except query for example).