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

Re: [HACKERS] Beta for 4:30AST ... ?

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Date: 2000-02-28 08:51:50
Message-ID: 38BA3726.4AA47F7D@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
> > >> insert OID = 9999 ( bit varying PGUID 1 1 ...
> > The space in the type name is gonna confuse things.
> > AFAICS the solution would have to be similar to what we already do for
> > CHARACTER VARYING: parse the type declaration specially in gram.y,
> > and translate it to an internal type name.
> Those are only workarounds on the backend level though. Every new hack
> like this will require fixing every client applicatiion to translate that
> type right. It's fine with CHARACTER VARYING, because VARCHAR is an
> official alias (although it's not the real type name, mind you), but there
> is no VARBIT or NVARCHAR. It seems that allowing something like
>         bit\ varying
> in the bootstrap scanner will solve the problem where it's being caused.
> Internal type names should go away, not accumulate. ;)

I'm not sure that I agree that multi-word character types are required
internally. Somehow that seems to just push the problem of
SQL92-specific syntax to another part of the code. We could just as
easily (?) translate *every* "xxx VARYING" to "varxxx" on input, and
do the inverse on output or pg_dump.

                      - Thomas

-- 
Thomas Lockhart				lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2000-02-28 09:10:59
Subject: Re: [HACKERS] A further thought on rule string size
Previous:From: Jose SoaresDate: 2000-02-28 08:44:57
Subject: Re: [GENERAL] AW: [HACKERS] TRANSACTIONS

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