Re: Proposal for resolving casting issues

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

In response to

Responses

Browse pgsql-hackers by date

  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