pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feed'literal' for numbers
2+ messages / 1 participants
[nested] [flat]
* 'literal' for numbers
@ 2011-02-08 01:58 Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 2+ messages in thread
From: Bruce Momjian @ 2011-02-08 01:58 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-docs
Robert Haas wrote:
> On Mon, Feb 7, 2011 at 10:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> 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, based on your logic, the 'return -1' should not be literal
because no one would type that in. Unless I hear otherwise I will work
on a patch to match the rules you outlined above.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: 'literal' for numbers
@ 2011-09-05 15:56 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 2+ messages in thread
From: Bruce Momjian @ 2011-09-05 15:56 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-docs
Bruce Momjian wrote:
> > 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, based on your logic, the 'return -1' should not be literal
> because no one would type that in. Unless I hear otherwise I will work
> on a patch to match the rules you outlined above.
FYI, here is what I thought was Robert's conclusion on this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2011-09-05 15:56 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-02-08 01:58 'literal' for numbers Bruce Momjian <bruce@momjian.us>
2011-09-05 15:56 ` Bruce Momjian <bruce@momjian.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox