Re: Prefered Types - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Prefered Types
Date
Msg-id 24092.1304449566@sss.pgh.pa.us
Whole thread Raw
In response to Re: Prefered Types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Prefered Types  (Зотов Роман <zotov@oe-it.ru>)
Re: Prefered Types  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
I wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> The interesting discussion is what happens next.  To me, this is all
>> related to this previous discussion:
>> http://archives.postgresql.org/pgsql-hackers/2010-09/msg00232.php

> Yeah, there doesn't seem like much point unless we have a clear idea
> what we're going to do with the change.

BTW, it occurs to me to wonder whether, instead of making types be more
or less preferred, we should attack the issue from a different direction
and assign preferred-ness ratings to casts.  That seems to be more or
less the direction that Robert was considering in the above-linked
thread.  I'm not sure it's better than putting the ratings on types ---
in particular, neither viewpoint seems to offer a really clean answer
about what to do when trying to resolve a multiple-argument function
in which one possible resolution offers a more-preferred conversion for
one argument but a less-preferred conversion for another one.  But it's
an alternative we ought to think about before betting all the chips on
generalizing typispreferred.

Personally I've always felt that the typispreferred mechanism was a bit
of a wart; changing it from a bool to an int won't improve that, it'll
just make it a more complicated wart.  Casts have already got a
standards-blessed notion that some are more equal than others, so
maybe attaching preferredness ratings to them will be less of a wart.
Not sure about it though.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: A small step towards more organized beta testing
Next
From: Simon Riggs
Date:
Subject: Re: Unlogged tables, persistent kind