Re: [HACKERS] DEFAULT fixed - Mailing list pgsql-hackers

> After further thought, I think this may be a more difficult and subtle
> issue than we've realized.  In the current state of the system, there
> are many places where you have a value that you can only know the type
> OID for, not atttypmod --- specifically, any intermediate expression
> result.  Barring reworking the entire function-call mechanism to pass
> atttypmod around, that's not going to be possible to change.

Yes, I agree this is true, and I am not really sure how we can handle
this.  The return of a char() field can probably assume that whatever
the length identified in the VARLENA length field is the proper length. 
varchar() is much more complicated.  Though the on-disk length doesn't
have to match the maximum length specified in the table creation
statement, we do need to truncate any overly long strings returned by
functions.

However, the good news is that there are only a few cases where we care
about atttypmod.  If we are returning rows to the user from a function,
we don't care.  They get whatever we produce.  The only cases we care
are in an INSERT, UPDATE, and now, as we have discovered, a DEFAULT
clause on a CREATE TABLE.  In all other cases, the atttypmod is not
needed.

I still need to figure out where INSERT into a char() gets the string
padded properly.  Time to fire up the ddd debugger, now that I have the
6.5 HISTORY file completed.

> The only context where you really know atttypmod is where you have
> just fetched a value out of a table column or are about to store a
> value into a table column.  When storing, you need to be prepared to
> coerce the given value to the right type if *either* type OID or
> atttypmod is different --- but, in general, you don't know atttypmod
> for the given value.  (In the cases I know of, you can deduce it by
> examining the value itself, but this requires type-specific knowledge.)

Yes, I see what you mean.

> So on the whole I think this is something that has to be dealt with
> at the point of storing data into a tuple.  Maybe we need a new
> fundamental operation for types that pay attention to atttypmod:
> "make this value match the typmod of the target column, which is
> thus-and-so".  Trying to attack the problem from the source side by
> propagating typmod all around the parser is probably doomed to failure,
> because there will be many contexts where there's no way to know it.

Excellent idea.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026