Teodor Sigaev <teodor@sigaev.ru> writes:
> I'm working on user-defined typmod and try to move all typmod calculations into
> type-specific functions. But there is a strange place:
>
> /*
> * exprTypmod -
> * returns the type-specific attrmod of the expression, if it can be
> * determined. In most cases, it can't and we return -1.
> */
...
> So, I can't understand why it's needed at all. First, it's returns length as
> typmod, second, it looks like optimization, but I don't believe in significant
> benefits... It's a constant coming from query. Am I missing something?
I think that comes into play in cases like the following:
postgres=# create table qux as (select 'foo'::bpchar, 'foo'::varchar, 0::numeric);
SELECT
postgres=# \d qux Table "public.qux"Column | Type | Modifiers
---------+-------------------+-----------bpchar | character(3) | varchar | character varying | numeric | numeric
|
Note that unlike most of the built-in types bpchar doesn't actually make much
sense without a typmod. NUMERIC, VARCHAR, etc can all exist without a typmod
and behave sensibly but bpchar without a typmod would just be a varchar. The
default for CHARACTER without a typmod is CHAR(1) which is what happens if you
do ::CHAR but I guess we don't want to do that for ::bpchar.
On the other hand I can manually create a table with a column of type bpchar
and it does behave like a varchar with strange comparison semantics so I guess
you could argue bpchar without a typmod isn't completely meaningless.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com