Re: Proposal for resolving casting issues
От | Peter Eisentraut |
---|---|
Тема | Re: Proposal for resolving casting issues |
Дата | |
Msg-id | Pine.LNX.4.44.0209161912550.1307-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Proposal for resolving casting issues (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposal for resolving casting issues
|
Список | pgsql-hackers |
Tom Lane writes: > I think we must extend pg_cast's castimplicit column to a three-way value: > * okay as implicit cast in expression (or in assignment) > * okay as implicit cast in assignment only > * okay only as explicit cast Viewed in isolation this looks entirely reasonable, but I think we would be adding a lot of infrastructure for the benefit of a relatively small number of cases. As the writer of a cast, this presents me with at least one more option than I can really manage. As the user of a cast, these options make the whole system nearly unpredictable because in any non-trivial expression each of these behaviors could take effect somehow (possibly even depending on how the inner expressions turned out). I am not aware of any programming language that has more than three castability levels (never/explicit/implicit). Finally, I believe this paints over the real problems, namely the inadequate and hardcoded type category preferences and the inadequate handling of numerical constants. Both of these issues have had adequate approaches proposed in the past and would solve this an a number of other issues. -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-hackers по дате отправления: