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

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