On Wed, 2007-01-17 at 16:15 +, Simon Riggs wrote:
> On Wed, 2007-01-17 at 10:05 -0500, Merlin Moncure wrote:
> > On 12/28/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > > On Thu, 2006-12-28 at 19:26 +, Simon Riggs wrote:
> > > > On Thu, 2006-12-14 at 12:04 +, Simon Riggs wrote:
> > > >
I have applied a modified version of this patch. We now print the
exception value in hex, and give a URL where the exception can be looked
up.
---
Bruce Momjian wrote:
>
> I did some research on this, and found a nice Win3
Bruce Momjian wrote:
>
> I have applied a modified version of this patch. We now print the
> exception value in hex, and give a URL where the exception can be looked
> up.
Humm, wouldn't it be more appropriate to put the URL in a errhint()
instead?
> + ereport(lev,
> +
> +
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > I have applied a modified version of this patch. We now print the
> > exception value in hex, and give a URL where the exception can be looked
> > up.
>
> Humm, wouldn't it be more appropriate to put the URL in a errhint()
> instead?
>
> > +
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> I have applied a modified version of this patch. We now print the
>> exception value in hex, and give a URL where the exception can be looked
>> up.
> Humm, wouldn't it be more appropriate to put the URL in a errhint()
> instead
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> I have applied a modified version of this patch. We now print the
> >> exception value in hex, and give a URL where the exception can be looked
> >> up.
>
> > Humm, wouldn't it be more appropriate to put th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It should not be there at all. Do you see URLs in any of our other
>> error messages?
> Sure, ideally, but how else can we give information about that hex
> value?
It's not the responsibility of that error message to tell someone to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Eisentraut asked:
> Could you provide a less hand-waving specification of this feature? At
> the moment it sounds like "This option does something fun, but we're
> not sure what it is.
Sure. Perhaps after I manage to convince Tom of its usefu
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It should not be there at all. Do you see URLs in any of our other
> >> error messages?
>
> > Sure, ideally, but how else can we give information about that hex
> > value?
>
> It's not the responsibility of that
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> It should not be there at all. Do you see URLs in any of our other
> > >> error messages?
> >
> > > Sure, ideally, but how else can we give information about that hex
> > > value?
>
bruce wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> It should not be there at all. Do you see URLs in any of our other
> > >> error messages?
> >
> > > Sure, ideally, but how else can we give information about that hex
> > > value?
> >
> > It
>>> Even if it were the responsibility of the error message to suggest this,
>>> a URL seems far too transient.
>> I agree; more so given that the URL points to the Wine project pages.
>> And it's not user documentation, but source code, which makes it less
>> appropriate.
>
> OK, so what suggesti
Bruce Momjian <[EMAIL PROTECTED]> writes:
> FYI, here are the URL's I mention in our source code:
> * Wine (URL used in our error messages) -
> * http://source.winehq.org/source/include/ntstatus.h
> * Descriptions -
> http://www.comp.nus.edu.sg/~wuyongzh/my_doc/ntstatus.txt
Magnus Hagander wrote:
> >>> Even if it were the responsibility of the error message to suggest this,
> >>> a URL seems far too transient.
> >> I agree; more so given that the URL points to the Wine project pages.
> >> And it's not user documentation, but source code, which makes it less
> >> appro
Bruce Momjian wrote:
> Magnus Hagander wrote:
> Even if it were the responsibility of the error message to suggest this,
> a URL seems far too transient.
I agree; more so given that the URL points to the Wine project pages.
And it's not user documentation, but source code, which m
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > FYI, here are the URL's I mention in our source code:
>
> > * Wine (URL used in our error messages) -
> > * http://source.winehq.org/source/include/ntstatus.h
> > * Descriptions -
> > http://www.comp.nus.edu.sg/
Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Magnus Hagander wrote:
> > Even if it were the responsibility of the error message to suggest this,
> > a URL seems far too transient.
> I agree; more so given that the URL points to the Wine project pages.
> And it's not user docu
Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> FYI, here are the URL's I mention in our source code:
>>> * Wine (URL used in our error messages) -
>>> * http://source.winehq.org/source/include/ntstatus.h
>>> * Descriptions -
>>> http:/
Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> FYI, here are the URL's I mention in our source code:
> >>> * Wine (URL used in our error messages) -
> >>> * http://source.winehq.org/source/include/ntstatus.h
> >
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > Bruce Momjian wrote:
> > >
> > > Agreed. I propose we put the file in src/tools/msvc and link to our CVS
> > > source tree or something.
> > >
> > Uh, AFAIK they're not MSVC specific, but also apply to mingw.
> > src/tools/msvc is msvc only - if
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> OK, maybe /doc or src/tools. A more radical approach would be to put
>> the list in our documentation, or have initdb install it.
> Why not put it in techdocs or some such?
I think we've learned by now that putting copies of ot
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> OK, maybe /doc or src/tools. A more radical approach would be to put
> >> the list in our documentation, or have initdb install it.
>
> > Why not put it in techdocs or some such?
>
> I think we've learned
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> Tom Lane wrote:
>> Basically this whole idea is misconceived. Just print the number
and
>> have done.
>
> And how do people interpret that number?
I understand that "people" Bruce-san is saying means PostgreSQL
developers, not ordinary users.
When ordin
Takayuki Tsunakawa wrote:
> From: "Bruce Momjian" <[EMAIL PROTECTED]>
> > Tom Lane wrote:
> >> Basically this whole idea is misconceived. Just print the number
> and
> >> have done.
> >
> > And how do people interpret that number?
>
> I understand that "people" Bruce-san is saying means PostgreSQ
OK, I have tested on MinGW and found I can use FormatMessage() to print
a description for all ERROR* system() failures, rather than print a hex
value. This removes the need for a URL or lookup of hex values.
Attached and applied.
-
> Well, I am thinking of cases where we the error can help the user
> diagnose the problem. I have found a way to print descriptions with
> FormatMessage(), and the codes without descriptions will just print
as
> hex.
I also think this is correct. Like errno and strerror() combination
on UNIX, d
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> OK, I have tested on MinGW and found I can use FormatMessage() to
print
> a description for all ERROR* system() failures, rather than print a
hex
> value. This removes the need for a URL or lookup of hex values.
> Attached and applied.
Excuse me if I'm
Takayuki Tsunakawa wrote:
> From: "Bruce Momjian" <[EMAIL PROTECTED]>
> > OK, I have tested on MinGW and found I can use FormatMessage() to
> print
> > a description for all ERROR* system() failures, rather than print a
> hex
> > value. This removes the need for a URL or lookup of hex values.
> >
From: "Bruce Momjian" <[EMAIL PROTECTED]>
Yes, you are 100% correct that I had exceptions and errors confused.
I
> have backed out the patch that used FormatMessage(), and instead of
> using a URL, the message is now:
>
> child process was terminated by exception %X
> See /include/ntstatus.h for a
Takayuki Tsunakawa wrote:
> From: "Bruce Momjian" <[EMAIL PROTECTED]>
> Yes, you are 100% correct that I had exceptions and errors confused.
> I
> > have backed out the patch that used FormatMessage(), and instead of
> > using a URL, the message is now:
> >
> > child process was terminated by exce
Bruce Momjian wrote:
> Takayuki Tsunakawa wrote:
>> From: "Bruce Momjian" <[EMAIL PROTECTED]>
>> Yes, you are 100% correct that I had exceptions and errors confused.
>> I
>>> have backed out the patch that used FormatMessage(), and instead of
>>> using a URL, the message is now:
>>>
>>> child proc
31 matches
Mail list logo
