Re: Case Insensitive Queries - Mailing list pgsql-sql
| From | Ian Lance Taylor |
|---|---|
| Subject | Re: Case Insensitive Queries |
| Date | |
| Msg-id | si8zjey5so.fsf@daffy.airs.com Whole thread Raw |
| In response to | Re: Case Insensitive Queries (Mark <mark@zserve.com>) |
| List | pgsql-sql |
Mark <mark@zserve.com> writes:
> with varchars, as I understand it (and postgresql may be different),
> each varchar field has a header that stores the length of the particular
> entry's length. Further, if the varchar field precedes another field,
> the system loses the ability to use fixed-length addressing to access
> the field after the varchar, since the system must determine on a
> case-by-case basis how to access the field after the varchar. It has to
> calculate the size of the varchar, add that to the start of the varchar
> (plus header length), and then it has the address of the next field.
> With non-variant char it is fixed length, so selects and updates operate
> much more quickly. Even the postgresql documentation asserts something
> similar to this:
>
> 'Both TEXT and VARCHAR() store only the number of characters in the
> string. CHAR(length) is similar to VARCHAR(), except it always stores
> exactly length characters. This type pads the value with trailing spaces
> to achieve the specified length, and provides slightly faster access
> than TEXT or VARCHAR().'
>
> Perhaps I am misinformed.
You are misinformed with respect to Postgres. The implementation of
CHAR(length) is just like the implementation of VARCHAR(). It stores
a header with the entry length. That header is considered in all
functions in the same way that the VARCHAR() header is.
I don't know what documentation you are quoting, but it seems somewhat
misleading to me.
Here is the comment from the implementation
(src/backend/utils/adt/varchar.c):
/** CHAR() and VARCHAR() types are part of the ANSI SQL standard. CHAR()* is for blank-padded string whose length is
specifiedin CREATE TABLE.* VARCHAR is for storing string whose length is at most the length specified* at CREATE TABLE
time.**It's hard to implement these types because we cannot figure out* the length of the type from the type itself. I
change(hopefully all) the* fmgr calls that invoke input functions of a data type to supply the* length also. (eg. in
INSERTs,we have the tupleDescriptor which contains* the length of the attributes and hence the exact length of the
char()or* varchar(). We pass this to bpcharin() or varcharin().) In the case where* we cannot determine the length, we
passin -1 instead and the input string* must be null-terminated.** We actually implement this as a varlena so that we
don'thave to pass in* the length for the comparison functions. (The difference between these* types and "text" is that
wetruncate and possibly blank-pad the string* at insertion time.)**
- ay 6/95*/
Ian