Re: Remaining 'needs review' patchs in July commitfest

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Remaining 'needs review' patchs in July commitfest
Дата
Msg-id 20150728200130.GF2441@postgresql.org
обсуждение исходный текст
Ответ на Remaining 'needs review' patchs in July commitfest  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Remaining 'needs review' patchs in July commitfest  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
Heikki Linnakangas wrote:
> 21 patches remain in Needs Review state, in the July commitfest. Some of
> them have a reviewer signed up. I have highlighted some of them below that
> worry me the most. What are we going to do about these? For each of them,
> I'd like the authors to have some idea on what they need to do to get the
> patch into committable state (or if the whole approach is going to be
> rejected), but I don't know what that advise should be.
> 
> >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?  I thought this effort was all
about multi-line single statements only.  I think the proposed patch to
integrate psql's lexer in pgbench is a reasonable step forward, but we
need it to use our standard technique of symlinking the .l file in place
via some additional lines in pgbench's Makefile rather than copying it.

> >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?

> >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.

> >Asynchronous execution on postgres-fdw
> 
> If we're going to have some sort of general-purpose Parallel node support
> soon, should we just forget about this? Or is it still useful? This adds a
> fair amount of new infrastructure, for a fairly niche feature..

-0.1 on this one.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Remaining 'needs review' patchs in July commitfest
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Planner debug views