[HACKERS] Feature freeze and the great elog changeover
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
Re: [HACKERS] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze and the great elog changeover
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze and the great elog changeover
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze and the great elog changeover
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Feature freeze and the great elog changeover
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Feature freeze and the great elog changeover
Paul Ramsey [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Feature freeze and the great elog changeover
Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] 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: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Feature freeze and the great elog changeover
Paul Ramsey [EMAIL PROTECTED] writes: I am probably just misunderstanding something. See http://candle.pha.pa.us/main/writings/pgsql/sgml/nls.html regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Feature freeze and the great elog changeover
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Feature freeze and the great elog changeover
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 ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
