On 07/28/2015 11:01 PM, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>>> pgbench - allow backslash-continuations in custom scripts
>>
>> Everyone wants the feature, using multi-line SELECTs in pgbench scripts, but
>> we don't seem to be reaching a consensus on how it should work. I think
>> we'll need to integrate the lexer, but it would be nice to still support
>> multi-statements as well, with some syntax.
>
> Excuse me -- what's a multi-statement?
Sending "SELECT 1; SELECT 2;" to the server in one Query message. I.e.
PQexec(conn, "SELECT 1; SELECT 2;").
If you put that on a single line in pgbench today, it will send it as
one message to the server. If we start using a lexer, and split that
into two, that's a change in behaviour. Not the end of the world, but it
would still be nice to be able to use multi-statements in pgbench, too.
>>> dblink: add polymorphic result functions
>>
>> Seems pretty ugly to me to add a dummy argument to functions, just so that
>> you can specify the result type. The problem it's trying to solve is real,
>> though. Should we take it as it is, or wait for some cleaner approach?
>
> Put like that, it does sound quite ugly. I take it we have no better
> alternative proposed?
Joe Conway suggested a more generic approach here:
http://www.postgresql.org/message-id/559A9643.9070409@joeconway.com. I'm
not sure why that was not pursued. It certainly seems better to me.
>>> Improving test coverage of extensions with pg_dump
>>
>> Do we want to have this in src/test/modules or src/bin/pg_dump/t?
>
> Are we testing pg_dump here, or are we testing extensions? If the
> former, src/bin/pg_dump/t seems best.
I think that's the crux of the disagreement :-).
- Heikki