Re: [HACKERS] Data types - Mailing list pgsql-hackers

>
> > > 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.

I thought about this.  Unless you are going to make such a thing for
each type, you are going to have to over-load the storage for each type,
so you would have something like:

    typedef numeric_typmod {
        char len;
        char prec;
    };

and cast the atttypmod int2 value into that structure, and read the
field as two one-byte fields.

> 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.

This should be possible.  Now that atttypmod is passed around the
backend through resdom, it should be available in almost all context.
The trick is to pass it to the type-specific conversion functions.
Should certainly be possible.  The initial implemenation of atttypmod
just passed it to input functions, and it was not passed through the
backend.  Now, it does, so we no longer do funny things with TupleDesc
in the executor for char() and varchar().  They now get their atttypmod
values set from Resdom, and those are passed to the output functions.

> 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.

Sounds like a plan.

> 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).

Let me know if you find any limitations.  Initially, it was limited only
to input, but now, it will be more useful.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)