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.
*/
int32
exprTypmod(Node *expr)
{
<skip>
case T_Const:
{
/* Be smart about string constants... */
Const *con = (Const *) expr;

switch (con->consttype)
{
case BPCHAROID:
if (!con->constisnull)
{
int32 len =
VARSIZE(DatumGetPointer(con->constvalue)) - VARHDRSZ;

/* if multi-byte, take len and find # characters */
if (pg_database_encoding_max_length() > 1)
len =
pg_mbstrlen_with_len(VARDATA(DatumGetPointer(con->constvalue)), len);
return len + VARHDRSZ;
}
break;
default:
break;
}
}
break;


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?



--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/

Search Discussions

  • Gregory Stark at Oct 3, 2006 at 2:52 pm

    Teodor Sigaev 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
  • Tom Lane at Oct 3, 2006 at 3:48 pm

    Gregory Stark writes:
    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:
    Note that unlike most of the built-in types bpchar doesn't actually make much
    sense without a typmod.
    You may be reading too much into it. Looking at the patch that
    introduced exprTypmod(), I think I may have just been interested
    in avoiding an unnecessary length-coercion function call when assigning
    a constant that was already of the correct length to a CHAR(N) column.
    I concur with Teodor that embedding this type-specific knowledge into
    exprTypmod probably isn't all that great an idea.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedOct 3, '06 at 2:39p
activeOct 3, '06 at 3:48p
posts3
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase