On Sun, Jan 22, 2012 at 1:13 AM, Euler Taveira de Oliveira <eu...@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.h operators 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers