Remaining 'needs review' patchs in July commitfest

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.

> multivariate statistics

This has been a long discussion. Are we getting close to a committable
state?

> COPY RAW

No consensus on whether to add this to the server's COPY command, or as
a new psql backslash option.

> Unique Joins

Kyotaro HORIGUCHI commented on this back in March, but no-one's reviewed
the latest version. It's a fairly big patch. I guess I'll review it if
no-one else does, but it's going to take me some time to really dig into
it...

> checkpoint continuous flushing

This does a big memory allocation at checkpoint, which Tom vehemently
objects to. I don't much like it either, although I would be OK with a
more moderately-sized allocation. It's not clear on what criteria this
should be accepted or rejected. What workloads need to be tested?

> plpgsql raise statement with context

Impasse. Everyone wants this feature in some form, but no consensus on
whether to do this client-side or server-side.

> Configurable location for extension .control files

Do we want this? In its current form? I feel that this isn't ready as it
is, but I'm not sure what to suggest instead.

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

> Improving test coverage of extensions with pg_dump

Do we want to have this in src/test/modules or src/bin/pg_dump/t?

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

- Heikki

--

- Heikki