Re: [PORTS] Port Bug Report: int2 negative numbers not parsed correctly

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Postgres Hackers List <hackers(at)postgresql(dot)org>
Cc: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, mdalphin(at)sanger(dot)otago(dot)ac(dot)nz
Subject: Re: [PORTS] Port Bug Report: int2 negative numbers not parsed correctly
Date: 1998-04-01 02:48:02
Message-ID: 3521AAE2.2907AC5F@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > I declared a column to be type "smallint". It works, except
> > when I attempt to enter a negative number at which time the
> > parser complains about its 'type'. See example, below.
> > mdalphin=> insert into test values (-1);
> > ERROR: parser: attribute 'number' is of type 'int2' but expression
> > is of type 'int4'
> This is a problem we have seen in a few places. It is caused by the
> negative sign being handled in an unusual way. No fix known yet.

There are two ways to address this for a fix as far as I can tell:

1) in the parser transformations (and/or in the optimizer), look for
unary minus operators on constants, and convert those node subtrees to
negative constant nodes.

2) try to do the right thing to convert types to be compatible with
target columns. I'm working on this topic now, but I'm planning on
addressing functions (first cut is done) and operators (starting now)
before looking at target columns. Hopefully all three areas will be
do-able.

Anyone interested in looking at (1)? I think it would be a good thing to
have even if (2) masks the problem away, unless of course the optimizer
already gets rid of function calls on constants by executing them before
run-time...

- Tom

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-04-01 04:24:26 Re: [PORTS] Port Bug Report: int2 negative numbers not parsed correctly
Previous Message Bruce Momjian 1998-03-31 21:54:08 Re: [PORTS] Port Bug Report: int2 negative numbers not parsed correctly