2009/2/11 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@gmail.com> writes: >> some years ago there was some plans about parser's extensibility. I am >> able write bison extensions, but I thing, so lot of work should be >> done via hooking of transform stage. > > This strikes me as next door to useless, because it can only handle > things that look like valid expressions to the existing grammar. > So pretty much all you can do is weird sorts of functions, which are > already accommodated at less effort with existing features such as > function overloading.
Usually we don't need change syntax. But we need to control of coercion stage. I afraid so function overloading is bad when there lot of combination, and polymorphic functions are not enough. for some cases we need more polymorphic types - anyelement1, anyelement2, anyarray1, ... > > A hook check in that particular place is not going to have negligible > performance impact, since it's going to be hit tens or hundreds or > thousands of times per query rather than just once. So it's going to > require more than a marginal use case to persuade me we ought to have > it. Because this stage isn't repeated (I don't expect bigger performance impact), it's similar to other's hooks. But, sure, wrong hook should do strange things. It's risk. + argument - it increase customisability and allows gentle syntax tuning. Function decode is first sample from today morning. regards Pavel Stehule > > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
