Lists: | pgsql-hackers |
---|
From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | src/backend/parser/parse_expr.c:exprTypmod() question |
Date: | 2006-10-03 14:39:28 |
Message-ID: | 45227620.4090306@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: src/backend/parser/parse_expr.c:exprTypmod() question |
Date: | 2006-10-03 14:51:58 |
Message-ID: | 87ven178q9.fsf@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Teodor Sigaev <teodor(at)sigaev(dot)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
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: src/backend/parser/parse_expr.c:exprTypmod() question |
Date: | 2006-10-03 15:48:22 |
Message-ID: | 26252.1159890502@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Teodor Sigaev <teodor(at)sigaev(dot)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