Re: [HACKERS] Problems on NUMERIC

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Jan Wieck <jwieck(at)debis(dot)com>
Cc: PostgreSQL HACKERS <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Problems on NUMERIC
Date: 1998-12-22 16:16:23
Message-ID: 367FC5D7.70B19F72@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> First I wonder why the can_coerce... stuff is #if'd out of
> parse_relation.c? For the NUMERIC type the
> numeric(num,typmod) must be called if someone does an
>
> INSERT INTO ... SELECT * FROM ...
>
> But it isn't. It is only called when there are calculations
> done on the columns. I also checked that for BPCHAR type and
> it simply throws an ERROR if the target's length doesn't
> match.

Sorry, I'm having trouble thinking of a case which does not behave
properly with the existing types. I've tried inserting varchar(10)
columns into a varchar(1) column, I've tried inserting int columns into
float columns, etc etc. How are you getting handleTargetColname() /
checkTargetTypes() called where it is rejecting things?

It may be that splitting that attribute field into two pieces for
NUMERIC is opening a can of worms, since there are specific assumptions
about what that field means throughout the code :(

Maybe we should think about how to isolate the type-specific
interpretation of that attribute field into a type-specific handler
routine? Ooh, that sounds like a pain...

- Tom

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1998-12-22 16:47:19 Re: [HACKERS] Problems on NUMERIC
Previous Message Jan Wieck 1998-12-22 15:53:46 Re: [HACKERS] Problems on NUMERIC