> > SQL doesn't naturally lend itself to full OO extensibility, but
> > we can extend the backend to handle syntax like
> >
> > typename(characteristic, characteristic,...)
> >
> > where the characteristics have properties stored in the
> > type/attribute system and the backend knows how to meld the type
> > with the support type info (e.g.
> > typeOutput = print("%s(%s)", typename, printTypeSupport) ).
> How does atttypmod fit/not fit the need here? It is passed to all
> input/output functions.
At the moment, atttypmod is defined to be a two byte integer. I believe
it is used to flag specific behaviors regarding type handling, and I'm
not sure that, for example, it gives enough info and flexibility to keep
track of both precision and scale for the numeric() type as well as do
it's other jobs.
atttypmod is passed to input/output routines, but I think we need a
callable routine to convert internal representations also. That is, the
input/output routines convert from and to C strings, but we also need a
way to "convert" a type to itself (e.g. char(x) to char(4)), checking
atttypmod and/or other type-specific information while doing so. It also
needs a convention of some sort, or built-in to tables, so that this can
be set up extensibly and on-the-fly by the parser code.
Maybe if there were a routine defined in pg_proc which took a type and
atttypmod as arguments and output that same type the parser could look
for that and wrap it in a function call when converting types to
targets. Maybe that would be enough? It would be similar to the "cast"
convention we've adopted. I need to understand atttypmod's usage and
capabilities better to know for sure; these are just my impressions
right now.
atttypmod's presence in the code is certainly a good marker of where
we'd need to look to make changes (using atttypmod or something else).
??
- Tom
