Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joerg Sonnenberger <joerg(at)bec(dot)de>, John Naylor <jcnaylor(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Date: 2019-01-04 22:36:15
Message-ID: 20190104223615.zz2xkwbseoeuzg6c@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-01-04 16:43:39 -0500, Tom Lane wrote:
> Joerg Sonnenberger <joerg(at)bec(dot)de> writes:
> >> * What's the generator written in? (if the answer's not "Perl", wedging
> >> it into our build processes might be painful)
>
> > Plain C, nothing really fancy in it.
>
> That's actually a bigger problem than you might think, because it
> doesn't fit in very nicely in a cross-compiling build: we might not
> have any C compiler at hand that generates programs that can execute
> on the build machine. That's why we prefer Perl for tools that need
> to execute during the build. However, if the code is pretty small
> and fast, maybe translating it to Perl is feasible. Or perhaps
> we could add sufficient autoconfiscation infrastructure to identify
> a native C compiler. It's not very likely that there isn't one,
> but it is possible that nothing we learned about the configured
> target compiler would apply to it :-(

I think it might be ok if we included the output of the generator in the
buildtree? Not being able to add keywords while cross-compiling sounds like
an acceptable restriction to me. I assume we'd likely grow further users
of such a generator over time, and some of the input lists might be big
enough that we'd not want to force it to be recomputed on every machine.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Molotkov 2019-01-04 22:41:43 Re: BUG #15446: Crash on ALTER TABLE
Previous Message Andres Freund 2019-01-04 22:25:42 Re: BUG #15446: Crash on ALTER TABLE