Re: Patch for 8.5, transformationHook - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Patch for 8.5, transformationHook
Date
Msg-id 162867790908100652p3084ef49ne905343079777bfc@mail.gmail.com
Whole thread Raw
In response to Re: Patch for 8.5, transformationHook  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
2009/8/10 Peter Eisentraut <peter_e@gmx.net>:
> On Sunday 09 August 2009 05:21:48 Jeff Davis wrote:
>> * If the hook can implement XML, should we refactor the XML support (and
>> COALESCE, etc.) to use the hook for the sake of consistency? If the hook
>> is not good enough for those features, that might indicate a problem.
>
> Well, for 8.4, I proposed to rewrite xmlconcat, which is currently part of
> that hardcoded XML support, into a variadic function.  That was shot down for
> some unclear backwards compatibility reason.  (I guess, someone might have
> created their own xmlconcat function in a public schema and would now be
> surprised that it's actually callable?!?)  With that in mind, what chances of
> success will a plan have that proposes to reimplement a bunch of core
> functionality like COALESCE in user space?
>
> Another example that was mentioned during PGCon and that these hooks may or
> may not be useful for is somehow de-hardcoding various SQL-standard
> parentheses-less functions such as current_timestamp (thus opening the door
> for implementing Oracle's sysdate in userspace), but it's again unclear to me
> whether that would not be objected to if those functions became subject to the
> schema search path.
>

This patch doesn't help with it. But I thing so we will have other
hook in transformation - column name. This hook will serve for
detection plpgsql variables in SQL statement. And this hook should be
used for some parentheses-less functions.

regards
Pavel
>


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Patch for 8.5, transformationHook
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] "could not reattach to shared memory" on Windows