"Andrew Dunstan" <andrew@dunslane.net> writes:
> ... The real issue is what types and type mechanisms should be in the
> postgresql core distribution. We won't win any thanks from anyone if we
> reduce them. Getting some types right is hard. There is no case that I can
> see for pushing timestamps, numerics, bitstrings or geometric or network
> types out of the core - they need all the support they can get. I'm also not
> sure which of these are required by the SQL spec.
Timestamps and numerics are definitely in the spec, geometric and
network types are definitely not. IIRC, bitstring types are in SQL99
but for some reason are deprecated in SQL2003 (if anyone knows the
reasoning behind the SQL committee's about-face on that, please clue
us in).
AFAICS, the main part of the type system that isn't modular is the
support for type parameters (a/k/a typmod), such as the maximum length
for varchar or the precision/scale for numeric. We could certainly
invent an API for interpreting such parameters. But in the current state
of the system the types that have such parameters have to be hard-wired
into the SQL grammar, and I don't see how to get rid of that hard-wiring
without breaking a whole lot of stuff. Any bison gurus hanging about?
regards, tom lane