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 по дате отправления: