Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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 

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



In response to


pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group