Re: Proposal for resolving casting issues - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Proposal for resolving casting issues
Date
Msg-id Pine.LNX.4.44.0209161912550.1307-100000@localhost.localdomain
Whole thread Raw
In response to Proposal for resolving casting issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal for resolving casting issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: 7.3 Beta Schema and pg_dump
Next
From: Tom Lane
Date:
Subject: Re: 7.3 Beta Schema and pg_dump