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
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 |