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

From Daniele Varrazzo
Subject Re: [HACKERS] 'text' instead of 'unknown' in Postgres 10
Date
Msg-id CA+mi_8bgbKLp7K_tEyUyfCn4fvafvPqXQGTqzjYTRd1xLqRP_A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] 'text' instead of 'unknown' in Postgres 10  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] 'text' instead of 'unknown' in Postgres 10  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On Tue, Feb 7, 2017 at 2:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniele Varrazzo <daniele.varrazzo@gmail.com> writes:
>> testing with psycopg2 against Postgres 10 I've found a difference in
>> behaviour regarding literals, which are returned as text instead of
>> unknown. ...
>> Is this behaviour here to stay? Is there documentation for this change?
>
> Yup, see
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1e7c4bb0049732ece651d993d03bb6772e5d281a
>
> The expectation is that clients will never see "unknown" output columns
> anymore.

Ok thank you, I'll document the change in behaviour.


> I don't have enough context to suggest a better definition for psycopg
> ... but maybe you could pay some attention to the Python type of the value
> you're handed?

In python the only type is the list, there is no specific "list of
integer" or such.


>> It seems
>> this behaviour cannot be maintained on PG 10 and instead users need to
>> specify some form of cast for their placeholder.
>
> Well, no version of PG has ever allowed this without a cast:
>
> regression=# select array[];
> ERROR:  cannot determine type of empty array
>
> so I'm not sure it's inconsistent for the same restriction to apply in the
> case you're describing.  I'm also unclear on why you are emphasizing the
> point of the array being empty, because '{1,2,3}'::unknown would have the
> same behavior.

The inconsistency is on our side: on python list [1,2,3] we generate
'ARRAY[1,2,3]', and empty lists are instead converted to '{}'
precisely because there is no such thing like unknown[] - nor we can
generate array[]::int[] because the Python list is empty and we don't
know if it would have contained integers or other stuff. Of course
this only works because we merge arguments in the adapter: moving to
use PQexecParams we couldn't allow that anymore and the user should be
uniformly concerned with adding casts to their queries (this is a
non-backward compatible change so only planned for a mythical psycopg3
version I've long desired to write but for which I have no resource).

Thank you for the clarification: I will assume the behaviour cannot be
maintained on PG 10 and think whether the treatment of '{}' is too
magical and drop it instead.


-- Daniele



pgsql-hackers by date:

Previous
From: Joel Jacobson
Date:
Subject: [HACKERS] Idea on how to simplify comparing two sets
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] pg_restore is broken on 9.2 version.