Re: Remaining 'needs review' patchs in July commitfest

2015-07-28 21:51 GMT+02:00 Heikki Linnakangas <hlinnaka(at)iki(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>