Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> There are an awful lot of places in our source tree where the error
> level is fixed.  We could invent a new construct, say ereport_error or
> so, that is just like ereport except that it takes no error-level
> parameter because it's hard-coded to ERROR.

> It would be a bit of a pain to change all of the existing call sites,
> but presumably it would dodge a lot of these issues about the way
> compilers optimize things, because we could simply say categorically
> that ereport_error NEVER returns.

Meh.  We've already got it working, and in a way that doesn't require
the compiler to understand __attribute__((noreturn)) --- it only has
to be aware that abort() doesn't return, in one fashion or another.
So I'm disinclined to run around and change a few thousand call sites,
much less expect extension authors to do so too.

(By my count there are about six thousand places we'd have to change.)

Note that whatever's going on on dugong is not a counterexample to
"got it working", because presumably dugong would also be misbehaving
if we'd used a different method of flagging all the ereports/elogs
as nonreturning.

			regards, tom lane

In response to

• Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) at 2013-01-15 19:40:36 from Robert Haas

pgsql-hackers by date

Next:	From: Kohei KaiGai	Date: 2013-01-15 20:02:50
	Subject: [sepgsql 1/3] add name qualified creation label
Previous:	From: Robert Haas	Date: 2013-01-15 19:55:34
	Subject: Re: Get current query in a trigger function