From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Subject: | Re: Support for XLogRecPtr in expand_fmt_string? |
Date: | 2012-07-03 18:59:00 |
Message-ID: | 201207032059.00518.andres@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tuesday, July 03, 2012 08:09:40 PM Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-07-03 19:10:31 | Re: Support for XLogRecPtr in expand_fmt_string? |
Previous Message | Tom Lane | 2012-07-03 18:52:51 | Re: Support for XLogRecPtr in expand_fmt_string? |