"David G. Johnston" writes:
> On Tue, May 24, 2022 at 7:42 AM Tom Lane wrote:
>> Perhaps we could improve matters like this?
>> -specified, the underlying data type's default collation is used.
>> +specified, the domain has the same collation behavior as its
>> +underlyin
Daniel Brinzila writes:
> I am a bit confused as to the following change:
>Stop using query-provided column aliases for the columns of whole-row
>variables that refer to plain tables (Tom Lane)
> Could someone please give an example of this scenario, one that works in
> 11.15 and another
I am a bit confused as to the following change:
-
Stop using query-provided column aliases for the columns of whole-row
variables that refer to plain tables (Tom Lane)
The column names in tuples produced by a whole-row variable (such as
tbl.* in contexts other than the top level
"Dirschel, Steve" writes:
> Is Postgres able to drive the query the same way with the NOT IN as the
> NOT EXISTS is doing or is that only available if the query has a NOT
> EXISTS?
NOT IN is not optimized very well in PG, because of the strange
semantics that the SQL spec demands when the sub-que
I think this explains the situation well:
https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_NOT_IN
On Tue, Jun 14, 2022 at 11:59 AM Dirschel, Steve <
steve.dirsc...@thomsonreuters.com> wrote:
> We are in the process of migrating from Oracle to Postgres and the
> following query does muc
We are in the process of migrating from Oracle to Postgres and the following
query does much less work with Oracle vs Postgres.
explain (analyze, buffers)
select favoritegr0_.FAVORITE_GROUP_SID as favorite1_2_, favoritegr0_.CHANGED as
changed2_2_, favoritegr0_.TYPE_DISCRIMINATOR as type_dis3_2_,
