Feature freeze and the great elog changeover

Good idea. This is similar to the pgindent run, though that usually
happens just _before_ beta.

---------------------------------------------------------------------------

Tom Lane wrote:

I had originally planned to spend the next week editing all the elog()
calls in the backend to convert them to ereport() format where helpful,
add SQLSTATE values, and update wording to match the style guidelines
that were agreed to awhile back.

However, it looks like the same reasons that were holding me back still
apply: any wholesale editing will likely break unapplied patches, plus
I'll have to go back through the code when those patches do get applied.
With folk scrambling to get last-minute stuff done before feature
freeze, these are not good side-effects.

What I'd like to do instead is try to get the editing done during the
interval between feature freeze and the start of beta (which we've
already agreed is July 1 - July 15). I do not feel that this violates
the spirit of "feature freeze", but does anyone want to object to that
plan?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Good idea. This is similar to the pgindent run, though that usually
happens just _before_ beta.

Right. It still should; I'd recommend we do that after I finish the
error message edits.

I think at least one person had volunteered to help with the editing;
that might be a good thing if they're still willing. There's something
upwards of 4000 elog calls to be looked at :-(

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Good idea. This is similar to the pgindent run, though that usually
happens just _before_ beta.

Right. It still should; I'd recommend we do that after I finish the
error message edits.

I think at least one person had volunteered to help with the editing;
that might be a good thing if they're still willing. There's something
upwards of 4000 elog calls to be looked at :-(

Do we get error numbers with that? :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I think at least one person had volunteered to help with the editing;
that might be a good thing if they're still willing. There's something
upwards of 4000 elog calls to be looked at :-(

Do we get error numbers with that? :-)

That is the point ... I'd not really be bothering otherwise ...

regards, tom lane

Lots of hardcoded english... is i8n something which gets raised often,
or is it lingue franca enough that people don't care? (Since all the
messages are going to be looked at anyways...)

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I think at least one person had volunteered to help with the editing;
that might be a good thing if they're still willing. There's something
upwards of 4000 elog calls to be looked at :-(

Do we get error numbers with that? :-)

That is the point ... I'd not really be bothering otherwise ...

--
__
/
| Paul Ramsey
| Refractions Research
| Email: pramsey@refractions.net
| Phone: (250) 885-0632
\_

Paul Ramsey <pramsey@refractions.net> writes:

Lots of hardcoded english...

What makes you think it's hardcoded? We've had internationalization
support for awhile. (One of the results I'd like to accomplish in this
pass is to reduce the number of "junk" messages that translators need to
look at, by merging near-duplicates and suppressing .po entries for
internal-can't-happen errors.)

regards, tom lane

Paul Ramsey <pramsey@refractions.net> writes:

I am probably just misunderstanding something.

See http://candle.pha.pa.us/main/writings/pgsql/sgml/nls.html

regards, tom lane

Tom Lane wrote:

Paul Ramsey <pramsey@refractions.net> writes:

Lots of hardcoded english...

What makes you think it's hardcoded? We've had internationalization
support for awhile. (One of the results I'd like to accomplish in this
pass is to reduce the number of "junk" messages that translators need to
look at, by merging near-duplicates and suppressing .po entries for
internal-can't-happen errors.)

Ignorance on my part, probably. You mentioned elog() so I grepped for it
and found lots of this stuff:

elog(FATAL, "data directory %s was not found", checkdir)
elog(FATAL, "could not read permissions of directory %s: %m",
checkdir);

I am probably just misunderstanding something.

P.

--
__
/
| Paul Ramsey
| Refractions Research
| Email: pramsey@refractions.net
| Phone: (250) 885-0632
\_

On Wed, 25 Jun 2003, Paul Ramsey wrote:

Ignorance on my part, probably. You mentioned elog() so I grepped for it
and found lots of this stuff:

elog(FATAL, "data directory %s was not found", checkdir)
elog(FATAL, "could not read permissions of directory %s: %m",
checkdir);

I am probably just misunderstanding something.

It's taken care of by the gettext system.

One thing that I would like to see in the future (but probably wont for
many years still) is a log file that is saved in a format like

"data directory %s was not found", "/usr/"

where you can view the log with some (gui och command-line) tool that
translates it when you look at it. Then anyone can look at the log using
their language and you don't have to decide one one language when you
start the server.

Maybe something for postgresql X.

--
/Dennis

On Wed, 25 Jun 2003, Tom Lane wrote:

I had originally planned to spend the next week editing all the elog()
calls in the backend to convert them to ereport() format where helpful,
add SQLSTATE values, and update wording to match the style guidelines
that were agreed to awhile back.

However, it looks like the same reasons that were holding me back still
apply: any wholesale editing will likely break unapplied patches, plus
I'll have to go back through the code when those patches do get applied.
With folk scrambling to get last-minute stuff done before feature
freeze, these are not good side-effects.

What I'd like to do instead is try to get the editing done during the
interval between feature freeze and the start of beta (which we've
already agreed is July 1 - July 15). I do not feel that this violates
the spirit of "feature freeze", but does anyone want to object to that
plan?

Based on the reasons given, it sounds like it would be more harmful not to
do it when things are supposed to be frozen ... no objections here ...