Implicit coercions need to be reined in
От | Tom Lane |
---|---|
Тема | Implicit coercions need to be reined in |
Дата | |
Msg-id | 25136.1006374273@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Implicit coercions need to be reined in
(Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Re: Implicit coercions need to be reined in (Peter Eisentraut <peter_e@gmx.net>) Re: Implicit coercions need to be reined in (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Currently, if PG has a single-argument function named after its result type, the function is assumed to represent a valid implicit type coercion. For example, I can do regression=# select now() || now(); ?column? ------------------------------------------------------------2001-11-21 15:12:13.226482-052001-11-21 15:12:13.226482-05 (1 row) because there is a function text(timestamp) returning text, and this function gets invoked implicitly. It strikes me that this is a bad idea, and will get a lot worse as we add more conversion functions. With enough implicit coercions one will never be entirely sure how the system will interpret a mixed-datatype expression. Nonetheless, having more conversion functions seems like a good idea --- I think there should be a numeric-to-text conversion function, for example, and someone was just complaining in pggeneral about the lack of a boolean-to-text coercion. The problem is that there's no way to create a conversion function without inducing an implicit coercion path (unless you give the function a nonobvious name). What I'd like to suggest (for 7.3 or later) is adding a boolean column to pg_proc that indicates "can be implicit coercion". A function for which this is not set can be used as an explicitly requested coercion, but not an implicit one. Thus it'd be possible to define text(boolean) and allow it to be called explicitly, without creating an implicit coercion path and thereby losing a lot of type safety. I have not gone over the existing implicit coercions to see which ones I like and don't like, but I think a good first cut at maintaining sanity would be to disable any cross-type-category implicit coercions. Thus, for example, int4 to float8 seems like an okay implicit coercion, but not int4 to text. Note that this would cause the system to reject some things it accepts now, for example: regression=# select 45::int4 || 66::int4;?column? ----------4566 (1 row) This sort of thing would need explicit coercions to text under my proposal. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: