Re: [HACKERS] Problems on NUMERIC
| От | Thomas G. Lockhart |
|---|---|
| Тема | Re: [HACKERS] Problems on NUMERIC |
| Дата | |
| Msg-id | 367FC5D7.70B19F72@alumni.caltech.edu обсуждение исходный текст |
| Ответ на | Problems on NUMERIC (jwieck@debis.com (Jan Wieck)) |
| Ответы |
Re: [HACKERS] Problems on NUMERIC
|
| Список | 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
В списке pgsql-hackers по дате отправления: