On 1/2/15, 4:18 PM, Tom Lane wrote:
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?
Realistically, how many non-developers actually use the intXX SQL names? I
don't think I've ever seen it; the only places I recall seeing it done are code
snippets on developer blogs. Everyone else uses smallint, etc.
I know we're all gun-shy about this after standard_conforming_strings, but that
affected *everyone*. I believe this change would affect very, very few users.
Also, note that I'm not talking about removing anything yet; that would come
later.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
