Re: [HACKERS] Parser bug (?)

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: Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Parser bug (?)
Date: 1998-12-13 13:31:38
Message-ID: 3673C1BA.BFDA7A8F@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Is this fixed?

No, not yet. Put it on the "show stopper" list for v6.4.1...

The explanation is that CHAR is a "keyword" so is passed from the
scanner to the parser explicitly, which then makes sure that the various
legal forms of char type declarations get translated into the internal
bpchar type.

However, tokens surrounded by double quotes are passed as IDENTs, which
bypasses this mechanism completely.

I'll look at modifying pg_dump to leave out the double quotes on type
fields unless there is mixed or upper case. Also, I'll look at having
some automatic conversions between bpchar and char (though this might
not be available for v6.4.1 since it may require catalog changes).

- Tom

> > This looks like a parser bug in 6.4. I found it while trying to run
> > pg_upgrade:
> > bray=> create table junk ("singleton" "char" default 'M');
> > ERROR: DEFAULT: const type mismatched
> > pg_dump puts all type names in double quotes, which triggers this
> > bug when pg_upgrade is run, with the result that the upgrade fails.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1998-12-13 17:23:38 Re: [HACKERS] COMMIT
Previous Message Thomas G. Lockhart 1998-12-13 13:22:54 Re: [HACKERS] ecpg man page