> commit a70f2a57f233244c0a780829baf48c624187d456
> Author: Tom Lane
> Date: Mon Nov 13 17:04:10 2023 -0500
>
>Don't try to dump RLS policies or security labels for extension objects.
(Thanks Tom!)
--Jacob
On Thu, Nov 9, 2023 at 11:02 AM Tom Lane wrote:
> I'm hearing nothing but crickets :-(
Yeah :/
Based on your arguments above, it sounds like your patch may improve
several other corner cases when backported, so that sounds good
overall to me. My best guess is that Timescale will be happy with
I wrote:
> Jacob Champion writes:
>> Is this approach backportable?
> The code fix would surely work in the back branches. Whether the
> behavioral change is too big to be acceptable in minor releases
> is something I don't have a strong opinion on.
I'm hearing nothing but crickets :-(
If
Jacob Champion writes:
> Is this approach backportable?
The code fix would surely work in the back branches. Whether the
behavioral change is too big to be acceptable in minor releases
is something I don't have a strong opinion on.
regards, tom lane
On Wed, Oct 18, 2023 at 1:25 PM Tom Lane wrote:
> Stephen Frost writes:
> > This change would mean that policies added by a user after the extension
> > is created would just be lost by a pg_dump/reload, doesn't it?
>
> Yes. But I'd say that's unsupported, just like making other ad-hoc
>
Stephen Frost writes:
> Greetings,
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I wrote:
>>> Why are we marking extension member objects as being subject to SECLABEL
>>> or POLICY dumping?
> This change would mean that policies added by a user after the extension
> is created would just be lost
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > Why are we marking extension member objects as being subject to SECLABEL
> > or POLICY dumping? As the comment notes, that isn't really sensible
> > unless what we are dumping is a delta from the extension's initial
> >
I wrote:
> Why are we marking extension member objects as being subject to SECLABEL
> or POLICY dumping? As the comment notes, that isn't really sensible
> unless what we are dumping is a delta from the extension's initial
> assignments. But we have no infrastructure for that, and none seems
>
Jacob Champion writes:
> v3 fixes a doc comment I forgot to fill in; there are no other code
> changes. To try to further reduce the activation energy, I've also
> attached an attempt at a backport to 11. The main difference is the
> absence of catalogIdHash, which showed up in 15, so we don't
Hi all,
v3 fixes a doc comment I forgot to fill in; there are no other code
changes. To try to further reduce the activation energy, I've also
attached an attempt at a backport to 11. The main difference is the
absence of catalogIdHash, which showed up in 15, so we don't get the
benefit of that
Thanks for the reviews, both of you!
On Fri, Jul 14, 2023 at 5:04 AM Andrew Dunstan wrote:
> Seems reasonable at first glance. Isn't it going to save some work anyway
> later on, so the performance hit could end up negative?
Theoretically it could, if the OID list sent during getPolicies()
On 2023-06-29 Th 12:24, Jacob Champion wrote:
On 3/20/23 10:43, Tom Lane wrote:
I'd be more willing to consider the proposed patch if it weren't such
a hack --- as you say, it doesn't fix the problem when the table has
policies, so it's hardly a general-purpose solution. I fear that it's
also
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Passes the default cases; Does not make any trivial changes to
On 3/20/23 10:43, Tom Lane wrote:
> I'd be more willing to consider the proposed patch if it weren't such
> a hack --- as you say, it doesn't fix the problem when the table has
> policies, so it's hardly a general-purpose solution. I fear that it's
> also fairly expensive: adding sub-selects to
14 matches
Mail list logo
