Re: [PATCH] backend: compare word-at-a-time in bcTruelen - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Date
Msg-id 1245359025.3895.307.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] backend: compare word-at-a-time in bcTruelen
List pgsql-hackers
On Thu, 2009-06-18 at 12:58 -0400, Tom Lane wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> > Tom Lane <tgl@sss.pgh.pa.us> wrote: 
> >> It would be way nicer if we could strip trailing blanks on storage,
> >> and then figure a way to either reconstitute them on output
>  
> > How about pushing it even farther back -- always keep them with
> > trimmed trailing spaces and add trailing spaces as required in
> > operator functions?
> 
> I think that's what I said.  AFAIK there isn't any place where we'd
> need to add back the spaces except the output function.  All the
> operators would be just as happy if the spaces weren't there.

The overall problem is that we expect the Datum's of a datatype to know
how to display themselves without any access to metadata.

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.

It would be good to have a generic way to specify formatting to a data
type at the point you are manipulating it, rather than globally.

That would be helpful because we currently have some very ugly things
like the DateStyle parameter. That effects the Input and Output of data
into Time/Date columns, forcing you to switch parameter values
constantly as you load/select data. The current way makes it impossible
to load data that has different date formats in different columns, for
example.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: 8.4 open item: copy performance regression?
Next
From: Tom Lane
Date:
Subject: Re: 8.4 open item: copy performance regression?