Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> It might seem a minor quibble, but it seems like a more reliable approach
> might be to cast to a 64 bit type and user a 64 bit int formatter.
int64 is a real pain to use in error messages because of the
machine-dependence of the format string --- the translation machinery
doesn't work reliably if you try to do
ereport(...errmsg("trouble at offset " UINT64_FORMAT, bigintvar));
because any given translator will see only one of the several possible
source strings. You can get around this if you have to (print the
bigint into a char[n] local array and then use %s in the message),
but it's not worth it when dealing with values that can't plausibly
overflow an int. I think Teodor fixed it the right way.
regards, tom lane
In response to
Responses
pgsql-hackers by date
| Next: | From: Tom Lane | Date: 2006-09-06 14:01:33 |
| Subject: Re: @ versus ~, redux |
| Previous: | From: Tim Tassonis | Date: 2006-09-06 13:56:27 |
| Subject: Re: Thought provoking piece on NetBSD |
pgsql-committers by date
| Next: | From: User H-saito | Date: 2006-09-06 16:07:40 |
| Subject: npgsql - Npgsql: The project file for VisualStudio2003 is added. |
| Previous: | From: Michael Meskes | Date: 2006-09-06 13:15:50 |
| Subject: Re: [COMMITTERS] pgsql: Second try committing the path changes. |