Re: Remaining 'needs review' patchs in July commitfest - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Remaining 'needs review' patchs in July commitfest
Date
Msg-id 55B7E492.2060208@iki.fi
Whole thread Raw
In response to Re: Remaining 'needs review' patchs in July commitfest  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Remaining 'needs review' patchs in July commitfest
Re: Remaining 'needs review' patchs in July commitfest
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
Next
From: Joe Conway
Date:
Subject: Re: A little RLS oversight?