Re: postgres_fdw: IMPORT FOREIGN SCHEMA ... LIMIT TO (partition) - Mailing list pgsql-hackers

From Bernd Helmle
Subject Re: postgres_fdw: IMPORT FOREIGN SCHEMA ... LIMIT TO (partition)
Date
Msg-id e8825ca0cfce497e8debe7de802d0713d93c7c79.camel@oopsware.de
Whole thread Raw
In response to Re: postgres_fdw: IMPORT FOREIGN SCHEMA ... LIMIT TO (partition)  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: postgres_fdw: IMPORT FOREIGN SCHEMA ... LIMIT TO (partition)  (Bernd Helmle <mailings@oopsware.de>)
List pgsql-hackers
Am Mittwoch, dem 24.03.2021 um 13:23 +0100 schrieb Matthias van de
Meent:
> Yes, but it should be noted that the main reason that was mentioned
> as
> a reason to exclude partitions is to not cause table catalog bloat,
> and I argue that this argument is not as solid in the case of the
> explicitly named tables of the LIMIT TO clause. Except if SQL
> standard
> prescribes otherwise, I think allowing partitions in LIMIT TO clauses
> is an improvement overall.

Don't get me wrong, i find this useful, too. Especially because it's a
very minor change in the code. And i don't see negative aspects here
currently, either (which doesn't mean there aren't some).

> 
> I myself have had this need, in that I've had to import some
> partitions manually as a result of this limitation. IMPORT FORAIGN
> SCHEMA really is great when it works, but limitations like these are
> crippling for some more specific use cases (e.g. allowing
> long-duration read-only access to one partition in the partition tree
> while also allowing the partition layout of the parents to be
> modified).

Interesting use case. 


-- 
Thanks,
    Bernd





pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: PoC/WIP: Extended statistics on expressions
Next
From: Tomas Vondra
Date:
Subject: Re: PoC/WIP: Extended statistics on expressions