On Thu, Feb 06, 2025 at 10:26:09AM -0600, Sami Imseih wrote:
> That makes sense. Thanks!
Committed.
--
nathan
> Given we don't have any other reports or opinions, I'm probably just going
> to apply the patch to v18.
That makes sense. Thanks!
Sami
On Wed, Feb 05, 2025 at 01:36:57PM -0600, Sami Imseih wrote:
>> so the only reason I can see
>> for not back-patching it is that it could lead to somewhat widespread
>> breakage for existing scripts, etc. which are arguably kind-of working
>> today.
>
> That is my thought for not backpatching. It'
On Feb 6, 2025 at 03:27 +0800, Sami Imseih , wrote:
> > Yeah, I'd rather error out than expect users to respond to warnings to the
> > effect of "hey, you told us to do something, but we did something else that
> > isn't what you asked us to do." That both retains the broken feature and
> > adds mo
> so the only reason I can see
> for not back-patching it is that it could lead to somewhat widespread
> breakage for existing scripts, etc. which are arguably kind-of working
> today.
That is my thought for not backpatching. It's not breaking the COPY
command, it's just not applying an optimizati
On Wed, Feb 05, 2025 at 01:11:44PM -0600, Sami Imseih wrote:
> I don't think we will need to backpatch, unless someone has a different
> opinion about this.
I think this falls into the category of a bug, so the only reason I can see
for not back-patching it is that it could lead to somewhat widesp
> Yeah, I'd rather error out than expect users to respond to warnings to the
> effect of "hey, you told us to do something, but we did something else that
> isn't what you asked us to do." That both retains the broken feature and
> adds more noise, neither of which seems desirable.
I agree.
Sami
On Wed, Feb 05, 2025 at 01:05:32PM -0600, Sami Imseih wrote:
>> Instead of throwing an error, how about we turn that into a warning?
>> This way, if someone is batch-importing data for multiple tables, it won´t
>> interrupt their script that generates a COPY for each table.
>> Is it better to give
my apologies for the top post in the last reply. I hit send too fast :)
I also created a CF entry for this https://commitfest.postgresql.org/52/5544/
I don't think we will need to backpatch, unless someone has a different
opinion about this.
Regards,
Sami
Thanks for the feedback!
> Instead of throwing an error, how about we turn that into a warning?
> This way, if someone is batch-importing data for multiple tables, it won’t
> interrupt their script that generates a COPY for each table.
> Is it better to give them a heads-up without making them mo
Hi,
Zhang Mingli
www.hashdata.xyz
On Feb 4, 2025 at 04:18 +0800, Sami Imseih , wrote:
>
> This really does not make sense as this
> optimization cannot be applied to a remote table and it
> can give a user a false impression that it was.
+1,
```
+ /*
+ * Raise an error on foreign tables as it's
> Unless there's some existing way to specify a FREEZE option in the FDW API
> (I assume there isn't), I agree with this.
I am not aware of any way to do this either as postgres_fdw is simply
using libpq.
> > I was also looking at why we block a parent from COPY FREEZE[1], but
> Commit 5c9a551 a
On Mon, Feb 03, 2025 at 02:18:21PM -0600, Sami Imseih wrote:
> I think we should just block Foreign tables as we do with
> partition tables. Attached patch does that.
Unless there's some existing way to specify a FREEZE option in the FDW API
(I assume there isn't), I agree with this.
> I was also
13 matches
Mail list logo
