Heikki Linnakangas <hlinnakan...@vmware.com> writes: > 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. I agree with that so far as the SQL name for the function goes, which is part of why I don't think we should rename anything at the SQL level. But right now at the C level, it's unclear how things should be named, and I think we don't really want a situation where the most appropriate name is so unclear and potentially confusing. We're surviving fine with "int32" in C meaning "int4" in SQL so far as the type names go, so why not copy that naming approach for function names? >> 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(). We don't have a lot of hesitation about breaking individual function calls in extensions, so long as (1) you'll get a compile error and (2) it's clear how to update the code. See for instance the multitude of cases where we've added new arguments to existing C functions. So I don't think this objection holds a lot of water, especially when (as you note) there's not that much reason to be calling most of these functions directly from C. 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