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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
Per Alvaro's advice, forking this from [1].
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 rethink commands/view.c's
editorializing of a view rule action query' range table
20 matches
Mail list logo
