On Fri, Feb 11, 2011 at 11:17 AM, Itagaki Takahiro <itagaki.takah...@gmail.com> wrote: > Did you measure the actual cost in the real world? If we are using > such a sensitive parser, it should be a problem even without the patch.
It *is* a problem without the patch! >> Adding unnecessary keywords is something to be avoided. > > Our conclusion is "we never support multiset syntax in the SQL standard", > right? If we think they are unnecessary, we cannot support it. No, my conclusion is that if we're not really doing what the standard says anyway, it's not worth the cost of the new keywords. Whether or not we'd be willing to pay the cost for an implementation that actually conformed with the standard is not something I believe we've decided. But it's not going to happen any time soon, because adding actual multiset types would bloat pg_type by another 50%, which is a cost I doubt that we will be willing to pay. I really hope someone will eventually fix things so that we don't need to add a new copy of every composite type definition for every collection type we want to support, but until that happens, there is not much chance of implementing this feature in a way that is actually standard-conforming. And until then, paying the extra parsing cost for something that isn't going to be standard behavior anyway is not a good trade-off. We have spent countless hours figuring out how to redesign bits of syntax so that they could use already-existing keywords instead of adding new ones; and many more hours angsting about whether there is any way to get rid of some of the keywords we already have. The new options syntax for EXPLAIN and VACUUM exists *primarily* to reduce the number of future keywords we'll need to create. This is a seriously annoying problem, but it's not one we made up just for this patch. We deal with it all the time. Do we sometimes add keywords? Sure, of course we do. But we try to minimize it. It isn't free. > I will remove parser changes from the patch; it will add only a few array > functions. Then, please let me know functions you don't want to include > in the core, if any. I'll remove them at the same time. I posted my thoughts on this topic a week ago. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
