Re: [HACKERS] GSoC 2017: Foreign Key Arrays - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Date
Msg-id 1fad85ba-547c-4292-8782-cb2733132149@www.fastmail.com
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Mark Rofail <markm.rofail@gmail.com>)
Responses Re: [HACKERS] GSoC 2017: Foreign Key Arrays
List pgsql-hackers
On Fri, Feb 12, 2021, at 20:56, Mark Rofail wrote:
>Attachments:
>anyarray_anyelement_operators-v2.patch

I've created a quite sophisticated test in PL/pgSQL,
that takes advantage of all the test data produced
by the official PostgreSQL regression test suite.

It goes through all tables and columns, and extracts values
for all the different types it can find.

It then uses these values to probe for differences between

    some_value::some_type = ANY(ARRAY[some_other_value]::some_other_type[])
and
   some_value::some_type <<@ ARRAY[some_other_value]::some_other_type[]

psql:type-test.sql:165: NOTICE:
========================
144 of 21632 tests failed.
========================

Out of these 144 differences found, this one was really interesting:

psql:type-test.sql:165: WARNING:
SQL queries produced different results:
SELECT '285970053'::pg_catalog."numeric" = ANY(ARRAY['285970053']::pg_catalog.float4[])
false
SELECT '285970053'::pg_catalog."numeric" <<@ ARRAY['285970053']::pg_catalog.float4[]
true

I don't see why one of them returns false and the other true?

If testing for equality:

SELECT '285970053'::pg_catalog.float4 = '285970053'::numeric;

You get "false".

So it looks like ANY() does the right thing here, and <<@ has a problem.

To run, first run the PostgreSQL regression tests, to produce data in the "regression" database.

Then run:

$ psql -f type-test.sql regression

/Joel
Attachment

pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: pg13.2: invalid memory alloc request size NNNN
Next
From: Erik Rijkers
Date:
Subject: Re: logical replication seems broken