Re: Implicit casts to text - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Implicit casts to text
Date
Msg-id 10870.1175532096@sss.pgh.pa.us
Whole thread Raw
In response to Re: Implicit casts to text  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Implicit casts to text  (Peter Eisentraut <peter_e@gmx.net>)
Re: Implicit casts to text  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Montag, 2. April 2007 09:17 schrieb Tom Lane:
>> The scheme that was in the back of my mind was to do this at the same
>> time as providing a general facility for casting *every* type to and
>> from text, by means of their I/O functions if no specialized cast is
>> provided in pg_cast.

> That's the first time I hear of such a scheme.

It's been discussed before, eg
http://archives.postgresql.org/pgsql-admin/2004-06/msg00390.php
http://archives.postgresql.org/pgsql-hackers/2004-10/msg00303.php

> Anyway, the point of this 
> exercise is to reduce misbehavior by explicit casting.  I don't see how 
> implicitly adding more casting paths helps that or is even related to that.

> Even if we had the automatic cast facility that you describe, and I find it 
> highly suspicious, such casts could at most be of the explicit category, so 
> how would that help users who currently rely on the implicit ones?

Certainly they'd all be explicit-only.  From a technical perspective
there's no need to do the two things at the same time; I'm just opining
that we could sell it easier if we did them together.  If we just do
this part, what users will see is that we broke their queries for what
to them will appear to be no particular gain.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: So are we calling it: Feature Freeze?
Next
From: Bruce Momjian
Date:
Subject: Re: Oracle indemnifies PostgreSQL on its patents