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

"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.

regards, tom lane