On Sun, Jan 22, 2012 at 1:13 AM, Euler Taveira de Oliveira
<euler@timbira.com> wrote:
> On 23-12-2011 12:05, Tom Lane wrote:
>> I too think a datatype is overkill, if we're only planning on providing
>> one function. Just emit the values as numeric and have done.
>>
> Here it is. Output changed to numeric.
Thanks!
When I compiled the source with xlogdiff.patch, I got the following warnings.
xlogfuncs.c:511:2: warning: format '%lX' expects argument of type
'long unsigned int *', but argument 3 has type 'uint64 *' [-Wformat]
xlogfuncs.c:511:2: warning: format '%lX' expects argument of type
'long unsigned int *', but argument 4 has type 'uint64 *' [-Wformat]
xlogfuncs.c:515:2: warning: format '%lX' expects argument of type
'long unsigned int *', but argument 3 has type 'uint64 *' [-Wformat]
xlogfuncs.c:515:2: warning: format '%lX' expects argument of type
'long unsigned int *', but argument 4 has type 'uint64 *' [-Wformat]
xlogfuncs.c:524:3: warning: format '%lX' expects argument of type
'long unsigned int', but argument 2 has type 'uint64' [-Wformat]
xlogfuncs.c:528:3: warning: format '%lX' expects argument of type
'long unsigned int', but argument 2 has type 'uint64' [-Wformat]
When I tested the patch, I got the following error:
postgres=# SELECT pg_current_xlog_location();pg_current_xlog_location
--------------------------0/2000074
(1 row)
postgres=# SELECT pg_xlog_location_diff('0/2000074', '0/2000074');
ERROR: xrecoff "2000074" is out of valid range, 0..A4A534C
In func.sgml <para> The functions shown in <xref linkend="functions-admin-backup-table"> assist in making on-line
backups. These functions cannot be executed during recovery. </para>
Since pg_xlog_location_diff() can be executed during recovery,
the above needs to be updated.
> While the output was int8 I could use
> pg_size_pretty but now I couldn't. I attached another patch that implements
> pg_size_pretty(numeric).
I agree it's necessary.
* Note: every entry in pg_proc.h is expected to have a DESCR() comment,* except for functions that implement
pg_operator.hoperators and don't* have a good reason to be called directly rather than via the operator.
According to the above source code comment in pg_proc.h, ISTM
pg_size_pretty() for numeric also needs to have its own DESCR().
+ buf = DatumGetCString(DirectFunctionCall1(numeric_out,
NumericGetDatum(size)));
+ result = strcat(buf, " kB");
According to "man strcat", the dest string must have enough space for
the result.
"buf" has enough space?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
