  Date: Sunday, October 22, 2000 @ 19:32:45
Author: tgl

Update of /home/projects/pgsql/cvsroot/pgsql/src/test/regress/expected
     from hub.org:/home/projects/pgsql/tmp/cvs-serv80691/src/test/regress/expected

Modified Files:
	plpgsql.out inet.out foreign_key.out errors.out 

-----------------------------  Log Message  -----------------------------

Some small polishing of Mark Hollomon's cleanup of DROP command: might
as well allow DROP multiple INDEX, RULE, TYPE as well.  Add missing
CommandCounterIncrement to DROP loop, which could cause trouble otherwise
with multiple DROP of items affecting same catalog entries.  Try to
bring a little consistency to various error messages using 'does not exist',
'nonexistent', etc --- I standardized on 'does not exist' since that's
what the vast majority of the existing uses seem to be.

Sun, 22 Oct 2000 19:32:46 -0400 (EDT)
Tom Lane <tgl@postgresql.org>
pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out
	errors.out)
> Modified Files:
...
> Some small polishing of Mark Hollomon's cleanup of DROP command: might
> as well allow DROP multiple INDEX, RULE, TYPE as well.  Add missing
> CommandCounterIncrement to DROP loop, which could cause trouble otherwise
> with multiple DROP of items affecting same catalog entries.  Try to
> bring a little consistency to various error messages using 'does not exist',
> 'nonexistent', etc --- I standardized on 'does not exist' since that's
> what the vast majority of the existing uses seem to be.

Good idea(s). Thanks for cleaning up the error messages...

                    - Thomas

Mon, 23 Oct 2000 06:53:42 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: pgsql/src/test/regress/expected (plpgsql.out inet.out
	foreign_key.out errors.out)
> > Modified Files:
> ...
> > Some small polishing of Mark Hollomon's cleanup of DROP command: might
> > as well allow DROP multiple INDEX, RULE, TYPE as well.  Add missing
> > CommandCounterIncrement to DROP loop, which could cause trouble otherwise
> > with multiple DROP of items affecting same catalog entries.  Try to
> > bring a little consistency to various error messages using 'does not exist',
> > 'nonexistent', etc --- I standardized on 'does not exist' since that's
> > what the vast majority of the existing uses seem to be.
> 
> Good idea(s). Thanks for cleaning up the error messages...

Speaking of error messages, one idea for 7.2 might be to prepended
numbers to the error messages.  That way, people could look up a more
detailed description of the error and possible causes.  Now, none of us
have the time to do that, but the new companies may, and they will need
those numbers to help with technical support anyway.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 23 Oct 2000 10:26:50 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: pgsql/src/test/regress/expected (plpgsql.out inet.out
	foreign_key.out errors.out)
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Speaking of error messages, one idea for 7.2 might be to prepended
> numbers to the error messages.

Isn't that long since on the TODO list?  I know we've had long
discussions about a thoroughgoing revision of error reporting.

			regards, tom lane

Mon, 23 Oct 2000 10:32:04 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql/src/test/regress/expected (plpgsql.out inet.out
	foreign_key.out errors.out)
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Speaking of error messages, one idea for 7.2 might be to prepended
> > numbers to the error messages.
> 
> Isn't that long since on the TODO list?  I know we've had long
> discussions about a thoroughgoing revision of error reporting.

Yes. We have:

	* Allow elog() to return error codes, not just messages
	* Allow international error message support and add error codes

I just thought I would mention it is on my radar screen now.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 23 Oct 2000 10:33:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: pgsql/src/test/regress/expected (plpgsql.out inet.out
	foreign_key.out errors.out)
Bruce Momjian writes:

> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Speaking of error messages, one idea for 7.2 might be to prepended
> > > numbers to the error messages.
> > 
> > Isn't that long since on the TODO list?  I know we've had long
> > discussions about a thoroughgoing revision of error reporting.
> 
> Yes. We have:
> 
> 	* Allow elog() to return error codes, not just messages
> 	* Allow international error message support and add error codes
> 
> I just thought I would mention it is on my radar screen now.

Yeah, it's on mine too.  The only thing I'm still unsure about the
"international" part.  Does anyone know of a gettext-ish thing that has an
acceptable license?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Mon, 23 Oct 2000 17:30:34 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: [COMMITTERS] pgsql/src/test/regress/expected (plpgsql.out
 inet.out
	foreign_key.out errors.out)
> Bruce Momjian writes:
> 
> > > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > > Speaking of error messages, one idea for 7.2 might be to prepended
> > > > numbers to the error messages.
> > > 
> > > Isn't that long since on the TODO list?  I know we've had long
> > > discussions about a thoroughgoing revision of error reporting.
> > 
> > Yes. We have:
> > 
> > 	* Allow elog() to return error codes, not just messages
> > 	* Allow international error message support and add error codes
> > 
> > I just thought I would mention it is on my radar screen now.
> 
> Yeah, it's on mine too.  The only thing I'm still unsure about the
> "international" part.  Does anyone know of a gettext-ish thing that has an
> acceptable license?

Yes, they must exist.  I want a solution that doesn't make it difficult
for people add error messages.  Having codes in the C files and error
messages in another file is quite a pain.  My idea would enable us to
number the error messages, keep the English text for the message in the
same file next to the code, then allow international support by creating
a utility that can dump out all the codes with the Engligh text to allow
translators to make non-English versions.  The translated file can then
be used by the backend to generate messages in other languagues using a
SET command.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 23 Oct 2000 11:33:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [COMMITTERS] pgsql/src/test/regress/expected (plpgsql.out
 inet.out
	foreign_key.out errors.out)
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Speaking of error messages, one idea for 7.2 might be to prepended
> > numbers to the error messages.
> 
> Isn't that long since on the TODO list?  I know we've had long
> discussions about a thoroughgoing revision of error reporting.

Yes, yes, yes! We need in numbers especially because of we
hopefully will have savepoints in 7.2 and so we would get powerful
error handling by *applications* not by *human* only.

Vadim



Mon, 23 Oct 2000 14:23:06 -0700
"Vadim Mikheev" <vmikheev@sectorbase.com>
Re: [HACKERS] Re: pgsql/src/test/regress/expected (plpgsql.out
	inet.out foreign_key.out errors.out)