Re: Cosmetic change in catalog/index.c

From: greg(at)turnstep(dot)com
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: Cosmetic change in catalog/index.c
Date: 2003-02-14 14:37:17
Message-ID: 616d0075632edd2e7af4c3734335e82c@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Conway wrote:
> On the contrary, I can't see any kind of consistency in the leading
> capitalization in elog() messages.

I actually only set out to fix one specific example,
the lowercase 'r' in:

ERROR: relation named "relation_name" already exists

when trying to create an index. When trying to create a table, sequence,
or view, the message is:

ERROR: Relation named "relation_name" already exists

so I went with the majority to force a consensus among otherwise identical
error messages. However, I felt silly making a one-letter patch, so made
some other changes in the file as well.

> If you're only going to make a few arbitrary changes but not make things
> consistent, it doesn't seem to be worth the risk of breaking client apps
> that examine error message strings.

Perhaps we need to re-examine error codes? Apps parsing message strings
seems dangerous. On the other hand, I would hope that a simple case change
would not break too many of them. And in the above example, the same error
is already returned two different ways.

Tom Lane writes:
> [consistency] There isn't any :-(. While I'd vote with Greg to migrate
> towards a consistent use of initial caps, I seem to recall that Peter
> was in favor of no initial caps ... which might help to explain why
> there's no consistency in the code now ...

My argument for initial caps is this: the error codes represent complete
sentences, and look better capitalized. The only exception should be
when an internal lowercase function name begins the error message, such
as:

elog(ERROR, "index_drop: cache lookup failed for index %u",

I am not totally opposed to leading with all lowercase if someone were to
present me with a good argument; more important is to pick one way and
stick with it to avoid problems like the one noted above.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200302140930

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE+TP4zvJuQZxSWSsgRAsXJAJ9IQh5y74QOsweEVjrE5/uax5kTnACgqZLr
6FPZYZZAt1+cb1uR3QxxNL8=
=Toij
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Kevin Brown 2003-02-14 19:17:53 stats_command_string default?
Previous Message Ian 2003-02-14 09:34:22 Acconuting Packages that use Postgres