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 BE962D1B50E for ; Thu, 1 Jul 2004 13:38:08 -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 35190-01 for ; Thu, 1 Jul 2004 16:38:08 +0000 (GMT) Received: from ex1.mtrex.com (unknown [65.162.166.21]) by svr1.postgresql.org (Postfix) with ESMTP id 3B8BDD1B50B for ; Thu, 1 Jul 2004 13:38:06 -0300 (ADT) Received: from jearl.mtrex.local ([10.10.210.11]) by ex1.mtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Jul 2004 10:38:03 -0600 Received: by jearl.mtrex.local (sSMTP sendmail emulation); Thu, 1 Jul 2004 10:38:03 -0600 To: Andreas Pflug Cc: Justin Clift , Tom Lane , PostgreSQL Hackers Mailing List Subject: Re: Adding column comment to information_schema.columns References: <40E37E3F.2050400@telstra.net> <22066.1088656403@sss.pgh.pa.us> <40E3949F.6020201@telstra.net> <40E3BB25.4020804@pse-consulting.de> From: jearl@bullysports.com Date: Thu, 01 Jul 2004 10:38:02 -0600 In-Reply-To: <40E3BB25.4020804@pse-consulting.de> (Andreas Pflug's message of "Thu, 01 Jul 2004 09:20:05 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 01 Jul 2004 16:38:03.0333 (UTC) FILETIME=[C75FF750:01C45F89] X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.3 tagged_above=0.0 required=5.0 tests=NO_REAL_NAME X-Spam-Level: X-Archive-Number: 200407/27 X-Sequence-Number: 55588 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 about being more tied to PostgreSQL would get some extra features. There is a huge difference between adhering to a standard and limiting yourself to a standard. The real question is whether PostgreSQL's goal is to support SQL standards, or whether PostgreSQL's goal is to give PostgreSQL users a useful set of tools. Jason Earl