Re: [HACKERS] 'text' instead of 'unknown' in Postgres 10 - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] 'text' instead of 'unknown' in Postgres 10
Date
Msg-id CAFj8pRC0c0w_f14MV5GONvVCMyV7gm6kWpmFB-3ZjLg3kaCtfQ@mail.gmail.com
Whole thread Raw
In response to [HACKERS] 'text' instead of 'unknown' in Postgres 10  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
List pgsql-hackers
Hi

2017-02-07 15:14 GMT+01:00 Daniele Varrazzo <daniele.varrazzo@gmail.com>:
Hello,

testing with psycopg2 against Postgres 10 I've found a difference in
behaviour regarding literals, which are returned as text instead of
unknown. In previous versions:

In [2]: cnn = psycopg2.connect('')
In [3]: cur = cnn.cursor()
In [7]: cur.execute("select 'x'")
In [9]: cur.description[0][1]
Out[9]: 705

In pg10 master:

In [10]: cnn = psycopg2.connect('dbname=postgres host=localhost port=54310')
In [11]: cur = cnn.cursor()
In [12]: cur.execute("select 'x'")
In [13]: cur.description[0][1]
Out[13]: 25

what is somewhat surprising is that unknown seems promoted to text "on
the way out" from a query; in previous versions both columns of this
query would have been "unknown".

postgres=# select pg_typeof('x'), pg_typeof(foo) from (select 'x' as foo) x;
 pg_typeof | pg_typeof
-----------+-----------
 unknown   | text

Is this behaviour here to stay? Is there documentation for this change?

In psycopg '{}'::unknown is treated specially as an empty array and
converted into an empty list, which allows empty lists to be passed to
the server as arrays and returned back to python. Without the special
case, empty lists behave differently from non-empty ones. It seems
this behaviour cannot be maintained on PG 10 and instead users need to
specify some form of cast for their placeholder. Previously this would
have worked "as expected" and the 4th argument would have been an
empty list:

cur.execute("SELECT %s, %s, %s, %s", (['x'], [42], [date(2017,1,1)],
[])); cur.fetchone()
(['x'], [42], [datetime.date(2017, 1, 1)], '{}')

Should I just take this test off from the test suite and document the
adapter as behaving differently on PG 10?

Thank you very much

I see similar issue in plpgsql_check

create function test_t(OUT t) returns t AS $$
begin
    $1 := null;
end;
$$ language plpgsql;

Now the "null" is text type implicitly ("unknown" was before)

select * from plpgsql_check_function('test_t()', performance_warnings := true);
                                plpgsql_check_function................................
--------------------------------------------------------------------------------------
 warning:42804:3:assignment:target type is different type than source type
 Detail: cast "text" value to "integer" type
 Hint: The input expression type does not have an assignment cast to the target type.
(3 rows)

It is a regression from my view - unknown had more sense in this case.

Regards

Pavel


 

-- Daniele


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Rushabh Lathia
Date:
Subject: [HACKERS] pg_restore is broken on 9.2 version.
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] 'text' instead of 'unknown' in Postgres 10