On Thu, Apr 11, 2019 at 10:50 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jeevan Chalke <jeevan.cha...@enterprisedb.com> writes: > > Do you mean, the code in get_collation_isdeterministic() should look like > > something like below? > > > If colloid = InvalidOid then > > return TRUE > > ELSE IF tuple is valid then > > return collisdeterministic from the tuple > > ELSE > > return FALSE > > I think it's appropriate to fail if we don't find a tuple, for any > collation oid other than zero. Again, if you trace through the > behavior of the longstanding collation check functions like > lc_ctype_is_c(), you'll see that that's what happens (except for > some hardwired OIDs that they have fast paths for). > OK. Attached patch which treats "collation 0" as deterministic in get_collation_isdeterministic() and returns true, keeping rest of the code as is. > regards, tom lane > -- Jeevan Chalke Technical Architect, Product Development EnterpriseDB Corporation The Enterprise PostgreSQL Company
diff --git a/src/backend/utils/cache/lsyscache.c b/src/backend/utils/cache/lsyscache.c index b4f2d0f..79e6484 100644 --- a/src/backend/utils/cache/lsyscache.c +++ b/src/backend/utils/cache/lsyscache.c @@ -945,6 +945,10 @@ get_collation_isdeterministic(Oid colloid) Form_pg_collation colltup; bool result; + /* Treat "collation 0" as deterministic. */ + if (!OidIsValid(colloid)) + return true; + tp = SearchSysCache1(COLLOID, ObjectIdGetDatum(colloid)); if (!HeapTupleIsValid(tp)) elog(ERROR, "cache lookup failed for collation %u", colloid); diff --git a/src/test/regress/expected/collate.out b/src/test/regress/expected/collate.out index 0dee7d7..a8e1f6e 100644 --- a/src/test/regress/expected/collate.out +++ b/src/test/regress/expected/collate.out @@ -676,13 +676,19 @@ SELECT collation for ((SELECT b FROM collate_test1 LIMIT 1)); "C" (1 row) +CREATE TABLE byteatable(a bytea primary key, b int); +SELECT * FROM byteatable WHERE a LIKE '%1%'; + a | b +---+--- +(0 rows) + -- -- Clean up. Many of these table names will be re-used if the user is -- trying to run any platform-specific collation tests later, so we -- must get rid of them. -- DROP SCHEMA collate_tests CASCADE; -NOTICE: drop cascades to 17 other objects +NOTICE: drop cascades to 18 other objects DETAIL: drop cascades to table collate_test1 drop cascades to table collate_test_like drop cascades to table collate_test2 @@ -700,3 +706,4 @@ drop cascades to table collate_test21 drop cascades to table collate_test22 drop cascades to collation mycoll2 drop cascades to table collate_test23 +drop cascades to table byteatable diff --git a/src/test/regress/sql/collate.sql b/src/test/regress/sql/collate.sql index 89de26a..124daf6 100644 --- a/src/test/regress/sql/collate.sql +++ b/src/test/regress/sql/collate.sql @@ -259,6 +259,9 @@ SELECT collation for ((SELECT a FROM collate_test1 LIMIT 1)); -- non-collatable SELECT collation for ((SELECT b FROM collate_test1 LIMIT 1)); +CREATE TABLE byteatable(a bytea primary key, b int); +SELECT * FROM byteatable WHERE a LIKE '%1%'; + -- -- Clean up. Many of these table names will be re-used if the user is -- trying to run any platform-specific collation tests later, so we
