On Thu, Apr 6, 2023 at 3:33 Tom Lane wrote:
> Amit Langote writes:
> > While thinking about query view locking in context of [1], I realized
> > that we have missed also fixing AcquirePlannerLocks() /
> > ScanQueryForLocks() to consider that an RTE_SUBQUERY rte may belong to
> > a view, which mu
I wrote:
> Amit Langote writes:
>> While thinking about query view locking in context of [1], I realized
>> that we have missed also fixing AcquirePlannerLocks() /
>> ScanQueryForLocks() to consider that an RTE_SUBQUERY rte may belong to
>> a view, which must be locked the same as RTE_RELATION ent
Amit Langote writes:
> While thinking about query view locking in context of [1], I realized
> that we have missed also fixing AcquirePlannerLocks() /
> ScanQueryForLocks() to consider that an RTE_SUBQUERY rte may belong to
> a view, which must be locked the same as RTE_RELATION entries.
I think
On Thu, Jan 12, 2023 at 10:06 AM Tom Lane wrote:
> Amit Langote writes:
> > On Mon, Jan 9, 2023 at 5:58 AM Tom Lane wrote:
> >> Conceivably we could make it work by allowing RTE_SUBQUERY RTEs to
> >> carry a relation OID and associated RTEPermissionInfo, so that when a
> >> view's RTE_RELATION R
Andrew Dunstan writes:
> On 2023-01-12 Th 09:54, Tom Lane wrote:
>> I was wondering whether we could store a per-version patch or Perl
>> script that edits the old dump file to remove known discrepancies
>> from HEAD.
> so, say in src/test/perl we have PostgreSQL/AdjustUpgrade.pm with a
> subrout
On 2023-01-12 Th 09:54, Tom Lane wrote:
>
> I was wondering whether we could store a per-version patch or Perl
> script that edits the old dump file to remove known discrepancies
> from HEAD. If well-maintained, that could eliminate the need for the
> arbitrary "fuzz factors" that are in TestUpg
Justin Pryzby writes:
> What about also including a dump from an old version, too ?
> Then the upgrade test can test actual upgrades.
The BF clients already do that (if enabled), but they work from
up-to-date installations of the respective branch tips. I'd not
want to have some branches includi
On Thu, Jan 12, 2023 at 09:54:09AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2023-01-12 Th 00:12, Justin Pryzby wrote:
> >> It's ugly and a terrible hack, and I don't know whether anyone would say
> >> it's good enough, but one could can probably avoid the diff like:
> >> sed -r '/CRE
Andrew Dunstan writes:
> On 2023-01-12 Th 00:12, Justin Pryzby wrote:
>> It's ugly and a terrible hack, and I don't know whether anyone would say
>> it's good enough, but one could can probably avoid the diff like:
>> sed -r '/CREATE/,/^$/{ s/\w+\.//g }'
> That looks quite awful. I don't think yo
On 2023-01-12 Th 00:12, Justin Pryzby wrote:
> On Wed, Jan 11, 2023 at 10:45:33PM -0500, Tom Lane wrote:
>> Amit Langote writes:
>>> On Thu, Jan 12, 2023 at 10:06 AM Tom Lane wrote:
I've pushed this with some cleanup --- aside from fixing
outfuncs/readfuncs, I did some more work on t
On Wed, Jan 11, 2023 at 10:45:33PM -0500, Tom Lane wrote:
> Amit Langote writes:
> > On Thu, Jan 12, 2023 at 10:06 AM Tom Lane wrote:
> >> I've pushed this with some cleanup --- aside from fixing
> >> outfuncs/readfuncs, I did some more work on the comments, which
> >> I think you were too slopp
On Thu, Jan 12, 2023 at 12:45 PM Tom Lane wrote:
> Amit Langote writes:
> > On Thu, Jan 12, 2023 at 10:06 AM Tom Lane wrote:
> >> I've pushed this with some cleanup --- aside from fixing
> >> outfuncs/readfuncs, I did some more work on the comments, which
> >> I think you were too sloppy about.
Amit Langote writes:
> On Thu, Jan 12, 2023 at 10:06 AM Tom Lane wrote:
>> I've pushed this with some cleanup --- aside from fixing
>> outfuncs/readfuncs, I did some more work on the comments, which
>> I think you were too sloppy about.
> Thanks a lot for the fixes.
It looks like we're not out
On Thu, Jan 12, 2023 at 10:06 AM Tom Lane wrote:
> Amit Langote writes:
> > On Mon, Jan 9, 2023 at 5:58 AM Tom Lane wrote:
> >> Conceivably we could make it work by allowing RTE_SUBQUERY RTEs to
> >> carry a relation OID and associated RTEPermissionInfo, so that when a
> >> view's RTE_RELATION
Amit Langote writes:
> On Mon, Jan 9, 2023 at 5:58 AM Tom Lane wrote:
>> Conceivably we could make it work by allowing RTE_SUBQUERY RTEs to
>> carry a relation OID and associated RTEPermissionInfo, so that when a
>> view's RTE_RELATION RTE is transmuted to an RTE_SUBQUERY RTE it still
>> carries
Amit Langote writes:
> I've attached just the patch that we should move forward with, as
> Alvaro might agree.
I've looked at this briefly but don't like it very much, specifically
the business about retroactively adding an RTE and RTEPermissionInfo
into the view's replacement subquery. That see
On Fri, 9 Dec 2022 at 12:20, Amit Langote wrote:
>
> On Fri, Dec 9, 2022 at 3:07 PM Amit Langote wrote:
> > On Thu, Dec 8, 2022 at 6:12 PM Alvaro Herrera
> > wrote:
> > > On 2022-Dec-07, Amit Langote wrote:
> > > > However, this
> > > > approach of not storing the placeholder in the stored rule
On 2022-Dec-07, Amit Langote wrote:
> However, this
> approach of not storing the placeholder in the stored rule would lead
> to a whole lot of regression test output changes, because the stored
> view queries of many regression tests involving views would now end up
> with only 1 entry in the ran
On Wed, Dec 7, 2022 at 6:42 PM Amit Langote wrote:
> Per Alvaro's advice, forking this from [1].
Forgot to add Alvaro.
> In light of my proposed changes to decouple permission checking from
> the range table on that thread (now committed as a61b1f7482), I had
> also been posting a patch there to
19 matches
Mail list logo