On Fri, Feb 11, 2011 at 11:17 AM, Itagaki Takahiro
<itagaki.takahiro@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
