Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group