Postgres Professional
   

Re: [DOCS] Avoiding upgrade backlash

From: Tom Lane
Subject: Re: [DOCS] Avoiding upgrade backlash
Date: ,
Msg-id: 18129.1194973903@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Avoiding upgrade backlash  (Peter Eisentraut)
List: pgsql-advocacy

Tree view

Avoiding upgrade backlash  (Josh Berkus, )
 Re: [DOCS] Avoiding upgrade backlash  (Tom Lane, )
 Re: Avoiding upgrade backlash  (Andrew Sullivan, )
  Re: Avoiding upgrade backlash  (Gregory Stark, )
   Re: Avoiding upgrade backlash  (Bruce Momjian, )
    Re: Avoiding upgrade backlash  (Andrew Sullivan, )
 Re: Avoiding upgrade backlash  (Peter Eisentraut, )
  Re: Avoiding upgrade backlash  (Stefan Kaltenbrunner, )
   Re: Avoiding upgrade backlash  (Bernd Helmle, )
  Re: Avoiding upgrade backlash  (Josh Berkus, )
   Re: [DOCS] Avoiding upgrade backlash  (Tom Lane, )
    Re: [DOCS] Avoiding upgrade backlash  ("Joshua D. Drake", )
  Re: [DOCS] Avoiding upgrade backlash  (Tom Lane, )
 Re: Avoiding upgrade backlash  ("Leif B. Kristensen", )
  Re: Avoiding upgrade backlash  (Alvaro Herrera <-ip.org>, )
   Re: Avoiding upgrade backlash  ("Leif B. Kristensen", )
    Re: Avoiding upgrade backlash  ("Leif B. Kristensen", )
     Re: Avoiding upgrade backlash  (Peter Eisentraut, )
      Re: Avoiding upgrade backlash  ("Leif B. Kristensen", )
       Re: Avoiding upgrade backlash  (Peter Eisentraut, )
        Re: Avoiding upgrade backlash  ("Leif B. Kristensen", )
     Re: Avoiding upgrade backlash  (Greg Smith, )
    Re: Avoiding upgrade backlash  (Jon Sime, ) 
Peter Eisentraut <> writes:
> Am Montag, 12. November 2007 schrieb Josh Berkus:
>> 3) If Robert gets his type-cast backport package together, the location of
>> that.

> Well, if you want to undo the changes, you don't need a backport
> package; you can just change the cast's definition.

It's actually not going to be that easy, because most of those casts
aren't even in pg_cast anymore: they have been subsumed into the
CoerceViaIO mechanism.  You'd need to resurrect the individual cast
functions before you could put entries back, too.

Another little problem is that you're likely to break as much stuff as
you fix.  An example in CVS HEAD:

regression=# select 42 || 'foo';
 ?column?
----------
 42foo
(1 row)

regression=# select 42 like 'foo';
ERROR:  operator does not exist: integer ~~ unknown
LINE 1: select 42 like 'foo';
                  ^
HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.

OK, let's "fix" that by making int->text implicit again:

regression=# create function inttotext(int) returns text as $$
regression$# begin return $1; end$$ language plpgsql strict immutable;
CREATE FUNCTION
regression=# create cast (int as text) with function inttotext(int)
regression-# as implicit;
CREATE CAST

Now LIKE works:

regression=# select 42 like 'foo';
 ?column?
----------
 f
(1 row)

but || not so much:

regression=# select 42 || 'foo';
ERROR:  operator is not unique: integer || unknown
LINE 1: select 42 || 'foo';
                  ^
HINT:  Could not choose a best candidate operator. You might need to add explicit type casts.

            regards, tom lane

pgsql-advocacy by date:

Previous:
From: Tom Lane
Date:
Subject: Re: [DOCS] Avoiding upgrade backlash
Next:
From: Decibel!
Date:
Subject: Re: Need for PostgreSQL demand?