Hi 2015-10-13 22:01 GMT+02:00 Robert Haas <robertmh...@gmail.com>:
> This patch is marked as Ready for Committer in the CommitFest > application. Here is my attempt to summarize the votes upthread: > > Tom Lane: plpgsql RAISE is sufficient; we don't need this. > Pavel Stehule: could be replaced by custom function, but not against it. > Robert Haas: plpgsql RAISE is sufficient; we don't need this. > Jim Nasby: A generic wrapper around RAISE is not trivial, so +1. > Andres Freund: I've written this function many times, so let's have it in > core. > David Fetter: I've written this function like 20 times, we should have it. > > I'm only -0 on this patch, so I won't yell and scream if some other > committer is prepared to step up and get this committed, but I'm not > excited about doing it myself on the strength of a weak consensus in > which I'm not a participant. Any takers? I recommend that we allow > this patch 30 days to attract an interested committer, and, if nobody > volunteers in that time, that we mark it Rejected for lack of > interest. > I am changing opinion little bit - the RAISE statement in plpgsql is really static for some purposes. The proposed function is much more dynamic due using VARIADIC params. It isn't possible with RAISE statement without some possible difficult modifications (difficult to find good consensus). The customized constructor for SPIError can do this work too, but it is not effective install and to use plpythonu for one functionality. More - proposed function is pretty simple without side effects - so maintenance of this function is not high. Regards Pavel > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >