From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MULTISET patch |
Date: | 2010-12-27 12:27:51 |
Message-ID: | AANLkTin6gNsa6uziUzH4LQgeMFQi_Z_pgiyH_vND85zV@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/12/27 Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>:
> On Mon, Dec 27, 2010 at 20:15, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>
DB2 use a both names. Almost all array functions has a name array_* .
Sure, standard is primary target. It's only my idea, so we can have a
both names. It's not significant.
>> 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.
>
It must not be done this commitfest. I agree, so we cant avoid
detoasting, but we can limit it with pg_detoast_datum_slice.
Pavel
>> 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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-12-27 13:25:29 | Re: Streaming replication as a separate permissions |
Previous Message | Itagaki Takahiro | 2010-12-27 12:21:39 | Re: MULTISET patch |