Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 1F6EF2E00A6 for ; Fri, 6 Jun 2008 21:42:59 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 25222-06-4 for ; Fri, 6 Jun 2008 21:42:35 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by developer.postgresql.org (Postfix) with ESMTP id 50AB02E00B9 for ; Fri, 6 Jun 2008 21:30:44 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m570Ufg6008460; Fri, 6 Jun 2008 20:30:41 -0400 (EDT) To: Greg Smith cc: Gregory Stark , pgsql-hackers@postgresql.org Subject: Re: Overhauling GUCS In-reply-to: References: <29525.1212613052@sss.pgh.pa.us> <48472E47.7030701@dunslane.net> <20080605162400.GF16502@alvh.no-ip.org> <48481CBF.6040602@enterprisedb.com> <48481E3A.4010306@hagander.net> <20080605174209.GL16502@alvh.no-ip.org> <20080605212129.GI14498@yugib.highrise.ca> <3F927D52-A0FD-4575-8D24-F0F70C459235@kineticode.com> <4848FAA6.8000903@pse-consulting.de> <87ej7aeuqx.fsf@oxford.xeocode.com> <4849137C.3040008@pse-consulting.de> <877id2erp6.fsf@oxford.xeocode.com> <48492356.4040506@pse-consulting.de> <1618.1212765176@sss.pgh.pa.us> <87d4muclr6.fsf@oxford.xeocode.com> Comments: In-reply-to Greg Smith message dated "Fri, 06 Jun 2008 17:38:38 -0400" Date: Fri, 06 Jun 2008 20:30:41 -0400 Message-ID: <8459.1212798641@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/335 X-Sequence-Number: 119448 Greg Smith writes: > On Fri, 6 Jun 2008, Gregory Stark wrote: >> "Greg Smith" writes: >>> 1) Is it worthwhile to expand the information stored in the GUC structure to >>> make it better capable of supporting machine generation and to provide more >>> information for tool authors via pg_settings? The exact fields that should or >>> shouldn't be included remains controversial; consider "default value", >>> "per-session/runtime/restart", and "enum lists" as the list of things that are >>> most needed there. >> >> Isn't that a list of what's *already* there? > I should have been clearer there. Some of the items suggested are already > in the structure, but aren't visible via pg_settings. Well, you can't see the default or reset values in pg_settings, only the current value. However, I fail to see the use of either of those for a configure wizard. It'll presumably be attached to a fresh connection so the reset value is not different from the current; and any decent wizard is going to know perfectly well what the defaults are. > ... In others (like the > suggestion to add a URL to the documentation) it is actually a new field > being added as well as its corresponding entry in the settings view. Offhand I would argue that we should choose the URLs in such a way that they can be derived automatically if you know the PG version number and GUC variable name. (We're almost there already, except that you have to know which section of the chapter it's in.) So the need to have a pg_settings column seems questionable --- seems like it would mostly be clutter. Perhaps instead of a view column, it would be useful to encapsulate the algorithm as a function? pg_variable_help_url(name) regards, tom lane