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/


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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

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/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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...6/msg00390.php
http://archives.postgresql.org/pgsql...0/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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Added to TODO:

* Allow all data types to cast to and from TEXT

http://archives.postgresql.org/pgsql...4/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. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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/

---------------------------(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

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. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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/

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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...6/msg00390.php
> http://archives.postgresql.org/pgsql...0/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/


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Peter,

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

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate