2015-07-28 21:51 GMT+02:00 Heikki Linnakangas <hlinn...@iki.fi>: > 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. >
the psql backslash option based patches was years old proposals - and years ago it was rejected. There is not any advantage of psql based solution. COPY based solution is simple and use current infrastructure and it works for input/output. For psql based solution we have to create infrastructure for import from zero. Some years ago I proposed to teach psql parametrized queries - this proposal was rejected. > > 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. > I sent two patches as example of two possible ways. The unfortunate thing is fact, so disagreement is on relative not important question. There are a precedents for both implementations - for first way - we have client_min_messages and log_min_messages, for second way we have VERBOSE levels in psql. At the end I don't think so there are any bigger difference for any user if we use one or second implementation. > > 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 >
