On Mon, Feb 7, 2011 at 10:08 AM, Tom Lane <[email protected]> wrote: > Robert Haas <[email protected]> writes: >> Which way did we more commonly do it before you applied this patch? > > We don't have a standard for this, and an undocumented patch applied > without any discussion doesn't create one. It's hopeless to imagine > that you'll ever achieve any uniformity that way. It won't last long > if you do, since you're outnumbered by committers who won't be following > whatever you think the convention is. > > I'm not even sure why you're trying --- I don't think it even makes > sense to try to have a standard about this. I can easily imagine that > integer constants might read better with <literal> in some contexts > and better without in others.
*reads patch more carefully* Here are my verdicts: advanced.sgml: good array.sgml: good backup.sgml: unsure catalogs.sgml: bad client-auth.sgml: bad config.sgml: bad func.sgml: bad high-availability.sgml: bad libpq.sgml: bad runtime.sgml: bad spi.sgml: unsure tsearch2.sgml: good So I guess I'm back agreeing with you. Basically, it seems like we ought to use <literal> if it's being used as a value that the user might want to supply (e.g. "if you set this parameter to 0, then no statements will be logged). It shouldn't use <literal> if it's just being used as a number (e.g. "this query will return all airplanes with a height of less than 30,000 feet"). The cases I'm unsure about are the ones where we're talking about a return value (e.g. in the event of an error, this function will return -1). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
