Re: Support for XLogRecPtr in expand_fmt_string? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Support for XLogRecPtr in expand_fmt_string?
Date
Msg-id 201207032059.00518.andres@2ndquadrant.com
Whole thread Raw
In response to Re: Support for XLogRecPtr in expand_fmt_string?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Support for XLogRecPtr in expand_fmt_string?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tuesday, July 03, 2012 08:09:40 PM Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > I wonder if we just should add a format code like %R or something similar
> > as a replacement for the %X/%X notion.
> Only if you can explain how to teach gcc what it means for elog argument
> match checking.  %m is a special case in that it matches up with a
> longstanding glibc-ism that gcc knows about.  Adding format codes of our
> own invention would be problematic.
Ah. Yes. That kills the idea.

> > Having to type something like "(uint32)
> > (state->curptr >> 32), (uint32)state->curptr" everywhere is somewhat
> > annoying.
> If we really feel this is worth doing something about, we could invent a
> formatting subroutine that converts XLogRecPtr to string (and then we
> just use %s in the messages).
I think that would make memory management annoying. Using a static buffer 
isn't going to work very well either because its valid to pass two recptr's to 
elog/ereport/....

I think at that point the current state is not worth the hassle, sorry for the 
noise.

Greetings,

Andres
-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Support for XLogRecPtr in expand_fmt_string?
Next
From: Tom Lane
Date:
Subject: Re: Support for XLogRecPtr in expand_fmt_string?