Alvaro Herrera <alvhe...@commandprompt.com> writes:
> Excerpts from Greg Stark's message of jue mar 03 13:02:53 -0300 2011:
>> But I'm not sure it's worth bothering. Filling in the description
>> field is hardly the most annoying part of adding pg_proc entries for
>> operators. If we could move most or all of the entries to an SQL file
>> so that we didn't have to deal with commutator and negator oids and
>> all that, that would save a lot of pain.
> You seem to want to have a completely new way to describe contents of
> pg_proc.h and pg_operator.h, from which the DATA and DESCR lines could
> be generated. Perhaps that's a worthy goal, not sure. I'm not sure it
> can be done with SQL though.
We've been around on that before. It'd probably be possible to reduce
pg_proc.h and pg_operator.h to some minimal set of functions/operators
needed to support the indexes on those catalogs, and then fill in the
rest using a higher-level notation; analogous to the difference in the
way we treat the bootstrap catalogs versus the rest of the catalogs.
I'm not really convinced that it's worth the trouble though. Making
up those DATA lines is not the hardest part of making a new built-in
function or operator; nor have I seen many errors in patches that
I think would have been avoided by a higher-level notation. (If memory
serves, by far the most common mistake in submissions against pg_proc.h
is failure to think carefully about the function's volatility marking.
A higher-level notation would help that not a whit.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
