Re: [HACKERS] Re: [DOCS] Re: FE/BE protocol revision patch

Again, old news, but am wading through my backlog.

Bruce Momjian and Tom Lane are discussing atttypmod, its uses, and prospects:
> >
> > Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > Zero overhead for types that don't use it is meaningless, because the
> > > varlena length is 4 bytes, while current atttypmod is only two. Second,
> > > I don't see how a varlena makes atttypmod less type-specific.
> >
> > Well, the issue is making sure that it will be adequate for future
> > datatypes that we can't foresee.
> >
> > I can see that a variable-size atttypmod might be a tad painful to
> > support. If you don't want to go that far, a reasonable compromise
> > would be to make it int4 instead of int2. int2 is already uncomfortably
> > tight for the numeric/decimal datatypes, which we surely will want to
> > support soon (at least I do ;-)). int4 should give a little breathing
> > room for datatypes that need to encode more than one subfield into
> > atttypmod.
>
> Comments? I am willing to change it.

An int 4 atttypmod should be fine. A bit of overhead perhaps, but who
quibles about a few bytes these days? And, perhaps there is a use.

Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at> add to the discussion:
>
> > Once atttypmod is exposed to applications it will be much harder to
> > change its representation or meaning, so I'd suggest getting this right
> > before 6.4 comes out. If that doesn't seem feasible, I think I'd even
> > vote for backing out the change that makes atttypmod visible until it
> > can be done right.
>
> atttypmod is the right direction, it only currently lacks extendability.
>
> Andreas

But, I think a line needs to be drawn. There is no way to forsee all the
possible uses to cover all future extendibility within the protocol. But,
the protocol should not be responsible for this anyway, that is really
the role of type implementation.

Right now the protocol supports some types (char, int, float etc) in a
special way. And it provides for composites. But it doesn't (and no-one
is arguing that it should) support images or sounds or timeseries in a
special way. The type itself has to handle that chore. All the protocol
really should do is provide a way to find the size and type of a value.
Which it does.

Numeric is a kind of borderline case. I think a perfectly good numeric
implementation could be made using varlenas to hold binary representations
of infinite precision scaled integers with precision and scale embedded in
the data. But, Numeric is an SQL92 type, and it is very common in SQL
applications and so the extra convenience of built-in support in the
protocol is probably justified. And, Numeric suport is something we know
about the need for now.

But, I don't think that spending a lot of effort or complicating the backend
code to support currently unknown and undefined possible future extensibility
is worthwhile.

My opinion only, but every project I have seen that started to get serious
about predicting future requireements ended up failing to meet known current
requirements.

-dg

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software 300 Lakeside Drive Oakland, CA 94612
- A child of five could understand this! Fetch me a child of five.