From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Proposal for resolving casting issues |
Date: | 2002-09-16 17:26:08 |
Message-ID: | Pine.LNX.4.44.0209161912550.1307-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-09-16 17:33:13 | Re: 7.3 Beta Schema and pg_dump |
Previous Message | Peter Eisentraut | 2002-09-16 17:25:48 | Re: 7.3 Beta Schema and pg_dump |