Re: Remaining 'needs review' patchs in July commitfest - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: Remaining 'needs review' patchs in July commitfest |
| Date | |
| Msg-id | CAFj8pRA7nQ0Z5Hyp8nYDJZsLNDjt-_t4EmvzGwiNcyGKqQZhrg@mail.gmail.com Whole thread Raw |
| In response to | Remaining 'needs review' patchs in July commitfest (Heikki Linnakangas <hlinnaka@iki.fi>) |
| List | pgsql-hackers |
2015-07-28 21:51 GMT+02:00 Heikki Linnakangas <hlinnaka@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
pgsql-hackers by date: