Re: pgbench - allow backslash-continuations in custom scripts - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgbench - allow backslash-continuations in custom scripts
Date
Msg-id 8412.1435938282@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgbench - allow backslash-continuations in custom scripts  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgbench - allow backslash-continuations in custom scripts  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
I wrote:
> As it stands, psqlscan.l has some external dependencies on the rest of
> psql, but we could perhaps refactor some of those away, and provide dummy
> implementations to satisfy others (eg pgbench could provide a dummy
> GetVariable() that just always returns NULL).

> So I'm imagining symlinking psqlscan.l into src/bin/pgbench and using it
> as-is (possibly after refactoring in psql).  A possible issue is avoiding
> unnecessary invocations of flex, though.  Maybe symlinking the .c file
> would work better.

A quick experiment with compiling psqlscan inside pgbench yields the
following failures:

pgbench.o: In function `psql_scan_setup':
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1239: undefined reference to `pset'
pgbench.o: In function `escape_variable':
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1950: undefined reference to `pset'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1950: undefined reference to `GetVariable'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1956: undefined reference to `pset'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1957: undefined reference to `psql_error'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1971: undefined reference to `pset'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1973: undefined reference to `psql_error'
pgbench.o: In function `evaluate_backtick':
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1701: undefined reference to `psql_error'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1712: undefined reference to `psql_error'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1722: undefined reference to `psql_error'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1728: undefined reference to `psql_error'
pgbench.o: In function `yylex':
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:511: undefined reference to `standard_strings'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:743: undefined reference to `pset'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:743: undefined reference to `GetVariable'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:751: undefined reference to `psql_error'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1037: undefined reference to `pset'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1037: undefined reference to `GetVariable'
pgbench.o: In function `psql_scan_slash_option':
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1619: undefined reference to `pset'
/home/postgres/pgsql/src/bin/pgbench/psqlscan.l:1628: undefined reference to `psql_error'

The pset references are to pset.encoding, pset.db, or pset.vars.  I'd
think the best way to deal with the encoding and connection are to pass
them as parameters to psql_scan_setup() which'd store them in 
the PsqlScanState.  pset.vars is only passed to GetVariable.  We could
refactor that away somehow (although actually, why wouldn't we want to
just implement variable substitution exactly like it is in psql?  Maybe
the right answer is to import psql/variables.c lock stock n barrel too...)
psql_error() and standard_strings() wouldn't be hard to provide.

So this is looking *eminently* doable.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [BUGS] BUG #13126: table constraint loses its comment
Next
From: Tom Lane
Date:
Subject: Re: psql :: support for \ev viewname and \sv viewname