On 23.01.2013 20:44, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
For all of that, I'm not sure that people failing to seek consensus
before coding is really so much of a problem as you seem to think.
For my part, I don't think the lack of consensus-finding before
submitting patches is, in itself, a problem.
I feel the same. Posting a patch before design and consensus may be a
huge waste of time for the submitter himself, but it's not a problem for
others.
The problem, imv, is that everyone is expecting that once they've
written a patch and put it on a commitfest that it's going to get
committed- and it seems like committers are feeling under pressure
that, because something's on the CF app, it needs to be committed
in some form.
I'm sure none of the committers have a problem rejecting a patch, when
there's clear grounds for it. Rejecting is the easiest way to deal with
a patch. However, at least for me, >50% of the patches in any given
commitfest don't interest me at all. I don't object to them, per se, but
I don't want to spend any time on them either. I can imagine the same to
be true for all other committers too. If a patch doesn't catch the
interest of any committer, it's going to just sit there in the
commitfest app for a long time, even if it's been reviewed.
As discussed, we really need to be ready to truely
triage the remaining patch set, figure out who is going to work on what,
and punt the rest til post-9.3.
FWIW, here's how I feel about some the patches. It's not an exhaustive list.
"Event Triggers: Passing Information to User Functions (from 2012-11)"
I don't care about this whole feature, and haven't looked at the patch..
Probably not worth the complexity. But won't object if someone else
wants to deal with it.
"Extension templates"
Same as above.
"Checksums (initdb-time)"
I don't want this feature, and I've said that on the thread.
"Identity projection (partitioning)"
Nothing's happened for over a month. Seems dead for that reason.
"Remove unused targets from plan"
Same here.
"Store additional information in GIN index"
Same here.
"Index based regexp search for pg_trgm"
I'd like to see this patch go in, but it still needs a fair amount of
work. Probably needs to be pushed to next commitfest for that reason.
"allowing privileges on untrusted languages"
Seems like a bad idea to me, for the reasons Tom mentioned on that thread.
"Skip checkpoint on promoting from streaming replication"
Given that we still don't have an updated patch for this, it's probably
getting too late for this. Would be nice to see the patch or an
explanation of the new design Simon's been working.
"Patch to compute Max LSN of Data Pages (from 2012-11)"
Meh. Seems like a really special-purpose tool. Probably better to put
this on pgfoundry.
"logical changeset generation v4"
This is a boatload of infrastructure for supporting logical replication,
yet we have no code actually implementing logical replication that would
go with this. The premise of logical replication over trigger-based was
that it'd be faster, yet we cannot asses that without a working
implementation. I don't think this can be committed in this state.
"built-in/SQL Command to edit the server configuration file
(postgresql.conf)"
I think this should be a pgfoundry project, not in core. At least for now.
"json generator function enhacements"
"Json API and extraction functions"
To be honest, I don't understand why the json datatype had to be
built-in to begin with. But it's too late to object to that now, and if
the datatype is there, these functions probably should be, too. Or could
these be put into a separate "json-extras" extension? I dunno.
"psql watch"
Meh. In practice, for the kind of ad-hoc monitoring this would be useful
for, you might as well just use "watch psql -c 'select ...' ". Yes, that
reconnects for each query, but so what.
"plpgsql_check_function"
I don't like this in its current form. A lot of code that mirrors
pl_exec.c. I think we'll have to find a way to somehow re-use the
existing code for this. Like, compile the function as usual, but don't
stop on error.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
