Re: Remaining 'needs review' patchs in July commitfest
От | Heikki Linnakangas |
---|---|
Тема | Re: Remaining 'needs review' patchs in July commitfest |
Дата | |
Msg-id | 55B7E492.2060208@iki.fi обсуждение исходный текст |
Ответ на | Re: Remaining 'needs review' patchs in July commitfest (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Remaining 'needs review' patchs in July commitfest
Re: Remaining 'needs review' patchs in July commitfest |
Список | 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 по дате отправления: