Re: [PATCH] backend: compare word-at-a-time in bcTruelen

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Дата
Msg-id 407d949e0906181554o952f7bs9d84532d26d7a1d4@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Jun 18, 2009 at 10:03 PM, Simon Riggs<simon@2ndquadrant.com> wrote:
>
> The overall problem is that we expect the Datum's of a datatype to know
> how to display themselves without any access to metadata.

Yes

> Another way of looking at this might be that we need a default FORMAT
> specifier associated with a column. Teradata used the FORMAT specifier
> on a column to allow you to specify a default format. That allowed you
> to specify leading/trailing zeros/spaces, decimal points and other
> characters.

I've suggested this in the past in the context of getting rid of the
"cash" data type.

However I'm not sure it solves this problem. In the case where we're
just outputing a column we could arrange to have the typmod pretty
easily. but what would you do if you had some complex expression which
happened to result in a char(). Say something like:

coalesce(nickname, name)

where both nickname and name are, say, char(50). Or for that matter
where they're two different length chars, like char(50) and char(100).

<brainstorming>We could add an integer prefix to the char() datatype
with the "total" length and then just not include the spaces. But that
would make it not binary compatible with text -- which would mean
implementing a whole bunch of casts and operators. Perhaps. I think we
already have rtrim as the cast in one direction and I think we already
have operators which is the whole trigger for the bcTrueLen thing
which started this thread. maybe it wouldn't really be that much of a
pain.</brainstorming>


-- 
greg
http://mit.edu/~gsstark/resume.pdf


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: 8.4 open item: copy performance regression?
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: 8.4 open item: copy performance regression?