Thread: Implicit casts to text

Implicit casts to text

From
Peter Eisentraut
Date:
The attached patch changes all implicit casts to text to assignment and 
cleans up the associated regression test damage.  This change has been 
discussed for the longest time; I propose that we bite the bullet and 
do it now.

The issue described in 
<http://archives.postgresql.org/pgsql-hackers/2007-02/msg01729.php> 
should also be fixed but can be considered separately later.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Re: Implicit casts to text

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> The attached patch changes all implicit casts to text to assignment and 
> cleans up the associated regression test damage.  This change has been 
> discussed for the longest time; I propose that we bite the bullet and 
> do it now.

[ I'm assuming this isn't an April-fool item, otherwise never mind ]

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.  This would improve functionality, thus providing
a salve to the annoyance of users whose code the restriction breaks:
we can certainly argue that it wouldn't do for all those automatically
created casts to be implicit.  At the same time it'd let us eliminate
redundant text-to/from-foo code that's currently in place for some but
not all datatypes.

If we do only the restrictive part of this, it's a harder sale.

So, +1 on the concept, but I think we want a larger patch, and it's
probably too late for that for 8.3.
        regards, tom lane


Re: Implicit casts to text

From
Peter Eisentraut
Date:
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.  This would improve functionality, thus providing
> a salve to the annoyance of users whose code the restriction breaks:
> we can certainly argue that it wouldn't do for all those automatically
> created casts to be implicit.  At the same time it'd let us eliminate
> redundant text-to/from-foo code that's currently in place for some but
> not all datatypes.

That's the first time I hear of such a scheme.  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?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Re: Implicit casts to text

From
Tom Lane
Date:
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


Re: Implicit casts to text

From
Bruce Momjian
Date:
Added to TODO:

* Allow all data types to cast to and from TEXT
 http://archives.postgresql.org/pgsql-hackers/2007-04/msg00017.php


---------------------------------------------------------------------------

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > The attached patch changes all implicit casts to text to assignment and 
> > cleans up the associated regression test damage.  This change has been 
> > discussed for the longest time; I propose that we bite the bullet and 
> > do it now.
> 
> [ I'm assuming this isn't an April-fool item, otherwise never mind ]
> 
> 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.  This would improve functionality, thus providing
> a salve to the annoyance of users whose code the restriction breaks:
> we can certainly argue that it wouldn't do for all those automatically
> created casts to be implicit.  At the same time it'd let us eliminate
> redundant text-to/from-foo code that's currently in place for some but
> not all datatypes.
> 
> If we do only the restrictive part of this, it's a harder sale.
> 
> So, +1 on the concept, but I think we want a larger patch, and it's
> probably too late for that for 8.3.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: Implicit casts to text

From
Peter Eisentraut
Date:
Am Montag, 2. April 2007 18:41 schrieb Tom Lane:
> 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.

I find this method of selling features very unusual.  The two issues under 
consideration have nothing in common except that they have "cast" in their 
subject line.  The reduction of implicit casts to text has to stand on its 
own: the purpose is to produce more reliable expression behavior.  Those 
whose queries this would break are not helped by having other casts available 
without work; they'd still have to do manual fixups.  So what we'd have 
is "Sorry, casting int to text implicitly doesn't work anymore, but instead 
you can cast $othertype to text explicitly."  How does that help anyone?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Re: Implicit casts to text

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Am Montag, 2. April 2007 18:41 schrieb Tom Lane:
> > 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.
> 
> I find this method of selling features very unusual.  The two issues under 
> consideration have nothing in common except that they have "cast" in their 
> subject line.  The reduction of implicit casts to text has to stand on its 
> own: the purpose is to produce more reliable expression behavior.  Those 
> whose queries this would break are not helped by having other casts available 
> without work; they'd still have to do manual fixups.  So what we'd have 
> is "Sorry, casting int to text implicitly doesn't work anymore, but instead 
> you can cast $othertype to text explicitly."  How does that help anyone?

I assumed the issue was that there might not be explicit casts for every
case were were now disallowing.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: Implicit casts to text

From
Peter Eisentraut
Date:
Am Dienstag, 3. April 2007 17:17 schrieb Bruce Momjian:
> I assumed the issue was that there might not be explicit casts for every
> case were were now disallowing.

My proposal is to "downgrade" some casts from implicit to assignment.  Tom's 
proposal is to add more casts at the level of explicit, which is farther 
below assignment.  No cast will be lost.
-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Re: Implicit casts to text

From
Peter Eisentraut
Date:
Am Montag, 2. April 2007 18:41 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.

> http://archives.postgresql.org/pgsql-admin/2004-06/msg00390.php
> http://archives.postgresql.org/pgsql-hackers/2004-10/msg00303.php

FWIW, is the attached patch about what you had in mind?  (It probably only 
covers "normal" types at the moment.)

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Re: Implicit casts to text

From
Josh Berkus
Date:
Peter,

Which precise implicit casts are we breaking?  Can we provide an exact list in 
the release notes?

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco


Re: Implicit casts to text

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> FWIW, is the attached patch about what you had in mind?  (It probably only 
> covers "normal" types at the moment.)

Hm, I hadn't realized that it would take as little work as that ...
I have an itchy feeling that you missed something but I'm not sure
what.

One thing I had wanted to do is take out the existing functions and
pg_cast entries that are effectively just providing hard-wired
equivalents to this, but that's merely housekeeping.
        regards, tom lane


Re: Implicit casts to text

From
Bruce Momjian
Date:
Where are we on this?

---------------------------------------------------------------------------

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > FWIW, is the attached patch about what you had in mind?  (It probably only 
> > covers "normal" types at the moment.)
> 
> Hm, I hadn't realized that it would take as little work as that ...
> I have an itchy feeling that you missed something but I'm not sure
> what.
> 
> One thing I had wanted to do is take out the existing functions and
> pg_cast entries that are effectively just providing hard-wired
> equivalents to this, but that's merely housekeeping.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: Implicit casts to text

From
Tom Lane
Date:
Bruce Momjian <bruce@momjian.us> writes:
> Where are we on this?

Since there weren't any objections, I guess we can do it ;-)

I'll try to do something with Peter's patch plus removing the deadwood.
Would you add his patch to the queue so I don't forget?
        regards, tom lane


Re: Implicit casts to text

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Where are we on this?
> 
> Since there weren't any objections, I guess we can do it ;-)
> 
> I'll try to do something with Peter's patch plus removing the deadwood.
> Would you add his patch to the queue so I don't forget?

Added.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: Implicit casts to text

From
Tom Lane
Date:
Awhile back I wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> FWIW, is the attached patch about what you had in mind?  (It probably only 
>> covers "normal" types at the moment.)

> Hm, I hadn't realized that it would take as little work as that ...
> I have an itchy feeling that you missed something but I'm not sure
> what.

On closer inspection, my gut feeling was right: this patch doesn't work,
because it assumes that I/O functions have the same calling conventions
as cast functions, which they don't --- the semantics for second and
third arguments, if used, are different.

We could tweak build_coercion_expression() to generate the correct
arguments, but there are more problems downstream, eg in
exprIsLengthCoercion() which will misinterpret the arguments in such
a node.  So I'm inclined to think that we really need a specialized
expression node type, perhaps "CoerceViaIO".  This might have some
usefulness in plpgsql too, if it could piggyback on that rather than
doing its own ad-hoc conversions.

An alternative, which would be less pretty but also less work, is to
implement the cast this way only for types with single-argument input
functions.  Those that require extra args would still have to have
explicit pg_cast entries.  The main problem with this is we can't
support varchar on the same basis as text, because its input function
wants extra arguments.

BTW, I note that uuid has snuck in with assignment casts to and from
text.  Is this really what we want if we're tightening up everything
else?
        regards, tom lane