On 01/02/2015 11:41 PM, Tom Lane wrote:
What might be worth trying is establishing a hard-and-fast boundary
between C land and SQL land, with bitwise names in C and bytewise names
in SQL. This would mean, for example, that int4pl() would be renamed to
int32pl() so far as the C function goes, but the function's SQL name would
remain the same.
I don't like that. I read int4pl as the function implementing plus
operator for the SQL-visible int4 datatype, so int4pl makes perfect sense.
That would introduce visible inconsistency between such
functions' pg_proc.proname and pg_proc.prosrc fields, but at least the
inconsistency would follow a very clear pattern. And I doubt that very
many user applications are depending on the contents of pg_proc.prosrc.
Someone might be doing
DirectFunctionCall2(int4pl, ...)
in an extension. Well, probably not too likely for int4pl, as you could
just use the native C + operator, but it's not inconceivable for
something like int4recv().
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
