Обсуждение: pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)

  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.

> 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

> > 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

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

> 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

> 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