Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Peter Geoghegan <peter@2ndquadrant.com>
From: Peter Geoghegan <peter@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Farina <daniel@heroku.com>, Robert Haas <robertmhaas@gmail.com>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-28T09:47:49Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
- 9dbf2b7d75de 9.2.0 cited
-
Extend the parser location infrastructure to include a location field in
- a2794623d292 8.4.0 cited
-
Teach eval_const_expressions() to simplify an ArrayCoerceExpr to a constant
- 6734182c169a 8.4.0 cited
[ also for the archives' sake ]
On 27 March 2012 22:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, testing function pointers for null is certainly OK --- note that
> all our hook function call sites do that. It's true that testing for
> equality to a particular function's name can fail on some platforms
> because of jump table hacks.
I was actually talking about stylistic iffiness. This seems contrary
to the standard, which states:
(ISO C 99 section 6.5.9.6)
"Two pointers compare equal if and only if both are null pointers,
both are pointers to the same object (...) or function,
both are pointers to one past the last element of the same array object,
or one is a pointer to one past the end of one array object and the
other is a pointer to the start of a different array object that happens
to immediately follow the first array object in the address space."
However, the fly in the ointment is IA-64 (Itanic), which apparently
at least at one stage had broken function pointer comparisons, at
least when code was built using some version(s) of GCC.
I found it a bit difficult to square your contention that performing
function pointer comparisons against function addresses was what
sounded like undefined behaviour, and yet neither GCC nor Clang
complained. However, in light of what I've learned about IA-64, I can
certainly see why we as a project would avoid the practice.
Source: http://gcc.gnu.org/ml/gcc/2003-06/msg01283.html
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services