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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
