Tom Lane writes:
> There's another issue, which is that the routines that implement
> operations for a particular type are generally named after the type's
> internal name. I trust you are not going to propose that we find a way
> to put spaces into C function names ;-). It seems to me that the
> confusion created by having support code named differently from the
> type's internal name is just as bad as having the internal name
> different from the external name.
>
> This being the case, it seems like "bit_varying" might be a reasonable
> compromise for the internal name, and that should work already...
Okay, that's the first reasonable argument I've heard in this thread, and
I'll buy it. Since correspondence between internal type names and function
names *is* achievable without hacks we might as well go for this one.
In turn I'm thinking that it might be nice to have a backend function like
format_type(name[, int4]) that formats an internal type and any size
modifier for client consumption, like
format_type('varchar', 8) => "CHARACTER VARYING(8)"format_type('my type') => "\"my
type\""format_type('numeric',{xxx}) => "NUMERIC(9,2)"
That could put an end to keeping track of backend implementation details
in psql, pg_dump, and friends.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
