| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Emmanuel Cecchet <manu(at)asterdata(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>, Selena Deckelmann <selenamarie(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: COPY enhancements |
| Date: | 2009-10-07 14:45:45 |
| Message-ID: | 4ACCA999.1090502@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> Emmanuel Cecchet wrote:
>>
>>> If you prefer to postpone the auto-partitioning to the next commit
>>> fest, I can strip it from the current patch and re-submit it for the
>>> next fest (but it's just 2 isolated methods really easy to review).
>>>
>
>
>> I certainly think this should be separated out. In general it is not a
>> good idea to roll distinct features together. It complicates both the
>> reviewing process and the discussion.
>>
>
> I think though that Greg was suggesting that we need some more thought
> about the overall road map. Agglomerating "independent" features onto
> COPY one at a time is going to lead to a mess, unless they fit into an
> overall design plan.
>
>
>
I don't disagree with that. But even if we get a roadmap of some set of
features we want to implement, rolling them all together isn't a good
way to go.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2009-10-07 14:55:10 | Re: Feature Suggestion: PL/Js |
| Previous Message | Gnanam | 2009-10-07 14:34:52 | Deadlock error in INSERT statements |