Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] varchar() vs char16 performance

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: t-ishii(at)sra(dot)co(dot)jp, hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] varchar() vs char16 performance
Date: 1998-03-16 15:12:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > >The char2,4,8,16 types seem to have no value-added over the
> > >better-supported char(), varchar(), text types; I am considering
> > >removing them from the backend, and instead have the parser
> > >transparently translate the types into varchar() or char()
> Maybe we just need to fix char[].

There are notes in the source code from Jolly wondering whether arrays
of char/varchar would work, and specifically disallowing it "for now".

imho, even though there is one user forcing arrays of single characters
by invoking char2, rather than using text and substrings, that is not
sufficient to keep this obsolete capability in the backend forever.

There are two ways to smoothly transition to a system in which char2-16
is not a native built-in type:

1) modify the parser to automatically translate char2-16 into
char(2-16). This will not allow arrays of char2.

2) put char2-16 into a user-loadable module, which could be configured
into the template1 database if the installer chooses. This would retain
all current char2-16 capabilities.

These options are mutually exclusive, since implementing (1) would mean
the parser would not allow user-defined types for (2).

I had thought that char2-16 add _no_ functionality over the char() and
varchar() types; Tatsuo points out at least one capability which they
have. Are there any others?

                  - Tom

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-03-16 15:17:42
Subject: Re: [HACKERS] DEC Alpha initdb partial fix
Previous:From: Vazsonyi Peter[ke]Date: 1998-03-16 14:37:50
Subject: recursive seek...?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group