Re: [HACKERS] Should cast to CHAR or NUMERIC enforce default length limit?

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
>> analyze.c would have to be responsible for
>> inserting the appropriate default length in place of -1 when processing
>> a column definition.

> Sounds good. My first inclination was to work this out in gram.y,
> which you could do pretty easily for TYPECAST rules,

I thought about that, but since the Typename production itself can't
do the right thing (it doesn't know its context), you'd have to patch
up after it in either TYPECAST or column definition rules. On the
whole, fixing things that the grammar can't easily get right seems like
it belongs in analyze.c.

> Eventually, this
> could even be a tunable parameter settable during the session (e.g.
> "SET DEFAULT PRECISION NUMERIC ...").

As I'm envisioning it, the only thing the default will be used for is
substituting a default precision into a "CREATE TABLE foo (bar numeric)"
command. So adjusting the default on-the-fly doesn't seem all that
useful --- it wouldn't affect previously-created tables.

I did speculate about the idea of not enforcing a default precision at
all. If we allowed the table to be created with atttypmod = -1, then
the effect would be that numeric values would get stored with whatever
precision appeared in the source value or came out of a calculation.
Such a numeric column would have no specific precision/scale, so it'd
be more like variable-width "text" than fixed-width "char". I'm not
sure if this is useful, and I am sure that it wouldn't be very
standard...

regards, tom lane