Re: Patch for 8.5, transformationHook

2009/4/20 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> On Monday 20 April 2009 09:52:05 Pavel Stehule wrote:
>> I don't believe so is possible to find other general solution. (or
>> better I didn't find any other solution). Tom has true,
>> transformationHook on expression is expensive. I thing, so hook on
>> function should be simple and fast - not all transformation's should
>> be simple defined via property - classic sample is "decode" like
>> functions, it needs procedural code.
>
> I find this all a bit premature, given that you haven't clearly defined what
> sort of user-visible functionality you hope to end up implementing.  Which
> makes it hard to argue why this or that approach might be better.
>

a) it allows procedural setting for parameter's transformation and checking

like fce(int, varchar, int, varchar, ....), fce(int, int, int,
varchar, varchar, varchar) ... there should be hundred patterns

b) it allows constructors for data types (ANSI SQL)

datatype(typefield1[, typefiedl2[, typefiedl3[, ...]]]) returns type

c) it allows named parameters with different syntax

like Oracle fcecall(a => 10, b => 30), like Informix fcecall(a = 10, b = 30)

d) with patch that allows named parameters with PostgreSQL syntax
(value AS name) it allows "smart parameters" - name isn't name of
variable, but label like SQL/XML

xmlforest(user_name, user_name AS "user name")

I hope so this is enough :)

Regards
Pavel