Thread: pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)
pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)
From
Tom Lane
Date:
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.
Re: pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)
From
Thomas Lockhart
Date:
> 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
Re: pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)
From
Bruce Momjian
Date:
> > 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
Re: pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)
From
Tom Lane
Date:
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
Re: pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)
From
Bruce Momjian
Date:
> 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
Re: [HACKERS] Re: pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)
From
"Vadim Mikheev"
Date:
> 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