> On 24 Jun 2022, at 18:30, Justin Pryzby wrote:
>
> On Fri, Jun 24, 2022 at 04:09:46PM +0500, Andrey Borodin wrote:
>> Hi everyone!
>>
>> Sorry for bumping old thread.
>
> Please find this newer thread+patch here ;)
> https://www.postgresql.org/message-id/20220614230949.gx29...@telsasoft.com
Justin Pryzby writes:
> I realized that my latest patch would break upgrades from old servers, which
> do
> not have array_position/s nor width_bucket, so ::reprocedure would fail.
> Maybe
> Andrey's way is better (checking proname rather than its OID).
proname is dangerous, because there's no
On Fri, Jun 24, 2022 at 04:09:46PM +0500, Andrey Borodin wrote:
> Hi everyone!
>
> Sorry for bumping old thread.
Please find this newer thread+patch here ;)
https://www.postgresql.org/message-id/20220614230949.gx29...@telsasoft.com
> On 25 May 2021, at 21:14, Justin Pryzby wrote:
> >
> > Such
> On 24 Jun 2022, at 16:09, Andrey Borodin wrote:
>
> Would it be backpatchable to add this check to pg_upgrade?
Just to be clear of what exactly I propose I drafted a patch. PFA.
I've tested it with PG13 and
CREATE AGGREGATE public.array_accum(anyelement) (
SFUNC = array_append,
STY
Hi everyone!
Sorry for bumping old thread.
> On 25 May 2021, at 21:14, Justin Pryzby wrote:
>
> Such aggregate functions should be dropped before upgrade/restore and then
> re-created afterwards using the "anycompatible" functions. The affected
> functions are: array_append, array_prepend, arr
On Fri, Jun 11, 2021 at 09:40:07PM -0400, Bruce Momjian wrote:
> On Fri, Jun 11, 2021 at 09:17:46PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > OK, I used some of your ideas and tried for something more general;
> > > patch attached.
> >
> > I think it's a good idea to mention custom
On Fri, Jun 11, 2021 at 08:19:48PM -0500, Justin Pryzby wrote:
> On Fri, Jun 11, 2021 at 09:12:55PM -0400, Bruce Momjian wrote:
> > OK, I used some of your ideas and tried for something more general;
> > patch attached.
>
> This is good.
>
> But I wonder if "dropped before upgrading" is too spec
On Fri, Jun 11, 2021 at 09:17:46PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I used some of your ideas and tried for something more general;
> > patch attached.
>
> I think it's a good idea to mention custom aggregates and operators
> specifically, as otherwise people will look at t
On Fri, Jun 11, 2021 at 09:12:55PM -0400, Bruce Momjian wrote:
> OK, I used some of your ideas and tried for something more general;
> patch attached.
This is good.
But I wonder if "dropped before upgrading" is too specific to pg_upgrade?
Dropping the aggregate before starting a backup to be re
Bruce Momjian writes:
> OK, I used some of your ideas and tried for something more general;
> patch attached.
I think it's a good idea to mention custom aggregates and operators
specifically, as otherwise people will look at this and have little
idea what you're on about. I just want wording li
On Fri, Jun 11, 2021 at 08:56:19PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I came up with the attached patch. This is one of the few cases
> > where the incompatibility is not clearly related to the feature, so I
> > left the existing item alone and just created a new one with the
Bruce Momjian writes:
> OK, I came up with the attached patch. This is one of the few cases
> where the incompatibility is not clearly related to the feature, so I
> left the existing item alone and just created a new one with the same
> commit message in the incompatibilities section.
I think p
On Tue, Jun 8, 2021 at 07:10:00PM -0500, Justin Pryzby wrote:
> On Tue, Jun 08, 2021 at 08:02:46PM -0400, Bruce Momjian wrote:
> > This involves creating an aggreate that _uses_ these array functions as
> > their state transition function?
>
> Yes
OK, I came up with the attached patch. This is
On Tue, Jun 08, 2021 at 08:02:46PM -0400, Bruce Momjian wrote:
> This involves creating an aggreate that _uses_ these array functions as
> their state transition function?
Yes
--
Justin
On Tue, Jun 8, 2021 at 05:56:18PM -0500, Justin Pryzby wrote:
> @Bruce: Would you add something about this to the release notes before beta2?
>
> I added it as an OpenItem.
OK, see below.
> On Tue, May 25, 2021 at 11:14:58AM -0500, Justin Pryzby wrote:
> > On Thu, May 20, 2021 at 07:35:10PM -04
@Bruce: Would you add something about this to the release notes before beta2?
I added it as an OpenItem.
On Tue, May 25, 2021 at 11:14:58AM -0500, Justin Pryzby wrote:
> On Thu, May 20, 2021 at 07:35:10PM -0400, Tom Lane wrote:
> > Justin Pryzby writes:
> > > On Wed, Nov 04, 2020 at 07:43:51PM -
On Thu, May 20, 2021 at 07:35:10PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > On Wed, Nov 04, 2020 at 07:43:51PM -0500, Tom Lane wrote:
> >> As was discussed in the thread leading up to that commit, modifying the
> >> signature of array_cat and friends could break user-defined operators
>
Justin Pryzby writes:
> On Wed, Nov 04, 2020 at 07:43:51PM -0500, Tom Lane wrote:
>> As was discussed in the thread leading up to that commit, modifying the
>> signature of array_cat and friends could break user-defined operators
>> and aggregates based on those functions. It seems to me that the
On Wed, Nov 04, 2020 at 07:43:51PM -0500, Tom Lane wrote:
> crake is showing xversion upgrade failures since 9e38c2bb50:
>
> pg_restore: error: could not execute query: ERROR: function
> array_cat(anyarray, anyarray) does not exist
> Command was: CREATE AGGREGATE "public"."array_cat_accum"("anya
I wrote:
> I think the most plausible response is to add this aggregate to the filter
> logic that already exists in the xversion tests. Perhaps we could
> alternatively change this test case so that it relies on some other
> polymorphic function, but I'm not quite sure what a good candidate
> wou
20 matches
Mail list logo
