From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Andreas 'ads' Scherbaum" <adsmail(at)wars-nicht(dot)de> |
Cc: | Christian Ullrich <chris(at)chrullrich(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pl/pgSQL, get diagnostics and big data |
Date: | 2016-03-11 23:16:46 |
Message-ID: | 17251.1457738206@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Andreas 'ads' Scherbaum" <adsmail(at)wars-nicht(dot)de> writes:
> On 09.02.2016 20:32, Christian Ullrich wrote:
>> To fix this, I think it will be enough to change the format strings to
>> use "%zu" instead of "%lu".
> Attached is a new version of the patch, with %lu replaced by %zu.
Nonono ... that just moves the portability problem to a different set of
platforms. "%z" means size_t, and sizeof(size_t) is not any more fixed
than sizeof(long). The right thing to use is UINT64_FORMAT.
+ /* Int64GetDatum() instead of UInt64GetDatum(),
+ because there is no UInt64GetDatum() */
+ Int64GetDatum(estate->eval_processed),
Although in practice you'd get the same conversion anyway, I'm thinking
it's time to fix that omission rather than just averting our eyes. The
use of int64 data isn't decreasing as time goes on.
These are small enough changes that there's no need for a new patch
submission. I'll take it from here, unless I find bigger issues.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2016-03-11 23:24:33 | Re: Background Processes and reporting |
Previous Message | Petr Jelinek | 2016-03-11 23:14:30 | Re: Relation extension scalability |