Re: polymorphic types - enforce casting to most common type automatically - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: polymorphic types - enforce casting to most common type automatically
Date
Msg-id CAFj8pRASK21JKz-OOfE_1vL+5oh_DTj9aCUu9Y7Ru+PuW3V5OQ@mail.gmail.com
Whole thread Raw
In response to Re: polymorphic types - enforce casting to most common type automatically  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers


2015-07-22 10:37 GMT+02:00 Heikki Linnakangas <hlinnaka@iki.fi>:
On 07/11/2015 12:19 AM, Pavel Stehule wrote:
2015-07-10 18:43 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

An example of what would presumably happen if we adopted this sort of rule
(I've not checked whether the patch as written does this, but it would
logically follow) is that appending a float to an integer array would
cause the whole array to be silently promoted to float, with attendant
possible loss of precision for existing array elements.

it is based on select_common_type() - so it is use only available implicit
casts.

Without patch:

postgres=# select pg_typeof(array_append('{1,2,3}'::int[], 1.2::float));
ERROR:  function array_append(integer[], double precision) does not exist

With patch:

postgres=# select pg_typeof(array_append('{1,2,3}'::int[], 1.2::float));
     pg_typeof
--------------------
 double precision[]
(1 row)


Yeah, I agree with Tom that we don't want that change in behaviour. I'll mark this as rejected.

ok.

I accept it - it introduce incompatible changes.

Still I am sure, so this behave is some what users expect, but it should not be introduced this way.

Any ideas how this issues can be solved?

Regards

Pavel
 
- Heikki


pgsql-hackers by date:

Previous
From: Marc Mamin
Date:
Subject: Re: pg_dump -Fd and compression level
Next
From: Bill Moran
Date:
Subject: Re: Anyone working on the TOAST items on the TODO list?