Re: Implicit casts to text

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implicit casts to text
Date: 2007-04-02 16:41:36
Message-ID: 10870.1175532096@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-04-02 17:06:18 Re: Oracle indemnifies PostgreSQL on its patents
Previous Message Joshua D. Drake 2007-04-02 16:40:28 So are we calling it: Feature Freeze?