On Mon, Dec 27, 2010 at 20:15, Pavel Stehule <pavel.steh...@gmail.com> wrote: > * trim_array - you use a deconstruct_array. It unpack all fields and > it could not be effective. Can we limit a unpacked array?
Sure, I'll optimize it. > I searched on net. This function has a little bit unconptual name - > DB2 use a synonym for this function array_trim. Can we use this > synonym too? IBM DB2 does use TRIM_ARRAY for the name, no? I believe it's the standard. http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.apdv.sqlpl.doc/doc/t0053491.html > Probably there could be a low level optimization - can we limit a > detoast processing? (It must not be a part of this patch). I think we could avoid deconstruct_array() in some spaces, but cannot avoid detoasting. > Questions: > should be a MULTISET, SUBMULTISET, MEMBER a reserved keywords? > I am for marking these words as reserved keywords, but it needs a wide > agreeement. Without agreement, I don't think so not optimal keyword > "OF" in MEMBER operator is significant issue. They are full-reserved keywords in the spec, but I'd like not to reserve them until we can do nothing but do so. To be honest, I cannot fix shift/reduce errors in an optional OF in the syntax even if I marked those variables as reserved keywords. Can I ask for your help about the usage of bison/flex for such case? + /* FIXME: OF is an option in the SQL standard, but I cannot solve + shift/reduce errors without OF. To solve the errors, we might need + to make OF, MEMBER, and/or SUBMULTISET to reserved keywords. They + are reserved keywords in the SQL standard. + */ -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
