Re: Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

po 8. 3. 2021 v 21:12 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> "Joel Jacobson" <joel(at)compiler(dot)org> writes:
> > If I understand it correctly, we don't need to run genbki.pl to compile
> PostgreSQL,
> > so someone wanting to compile PostgreSQL without having a running
> PostgreSQL-instance
> > could do so without problems.
> > A dependency on having a PostgreSQL instance running,
> > is perhaps acceptable for hackers developing PostgreSQL?
> > But of course not for normal users just wanting to compile PostgreSQL.
> > If we think there is at least a 1% chance this is a feasible idea,
> > I'm willing to try implementing a SQL/PLpgSQL-version of genbki.pl.
>
> No, I think this is a non-starter. Bootstrapping from just the
> contents of the git repo is something developers do all the time
> (and indeed the buildfarm does it in every run). We do not want to
> need a running PG instance in advance of doing that.
>
> Yeah, we could make it work if we started treating all the genbki
> output files as things to include in the git repo, but I don't think
> anybody wants to go there.
>
> I understand some folks' distaste for Perl, and indeed I don't like it
> that much myself. If we were starting over from scratch I'm sure
> we'd choose a different language for our build/test infrastructure.
> But that's where we are, and I would not be in favor of having more
> than one scripting language as build requirements. So Perl is going
> to be it unless somebody gets ambitious enough to replace all the Perl
> scripts at once, which seems unlikely to happen.
>
> > I agree, I like the 2-D array version, but only if a we could provide a
> C-function
> > to allow unnesting N+1 dims to N dims. Is that a fruitful idea, or are
> there
> > reasons why it cannot be done easily? I could give it a try, if we think
> it's a good idea.
>
> +1, I think this need has come up before. My guess is that the
> hardest part of that will be choosing a function name that will
> satisfy everybody ;-).
>
> Could there be any value in allowing unnesting a variable number
> of levels? If so, we could dodge the naming issue by inventing
> "unnest(anyarray, int) returns anyarray" where the second argument
> specifies the number of subscript levels to remove, or perhaps
> the number to keep.
>

so what about?

CREATE OR REPLACE FUNCTION unnest_slice(anyarray, int)
RETURNS SETOF anyarray AS $$
DECLARE r $1%type;
BEGIN
FOREACH r SLICE $2 IN ARRAY $1 --- now $2 should be constant
LOOP
RETURN NEXT r;
END LOOP;
END;
$$ LANGUAGE plpgsql;

Regards

Pavel

regards, tom lane
>
>
>