Re: WIP: hooking parser - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: hooking parser
Date
Msg-id 17766.1235070126@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: hooking parser  (Sam Mason <sam@samason.me.uk>)
Responses Re: WIP: hooking parser  (Sam Mason <sam@samason.me.uk>)
Re: WIP: hooking parser  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Sam Mason <sam@samason.me.uk> writes:
> On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
>> AFAIK, the Oracle behavior is just about entirely unrelated to the
>> parser --- it's a matter of runtime comparison behavior.  It is
>> certainly *not* restricted to literal NULL/'' constants, which is the
>> only case that a parser hack can deal with.

> How about introducing a "varchar2" type as in Oracle?

Maybe.  I think right now we don't allow input functions to decide
that a non-null input string should be converted to a NULL, but
that might be fixable.  It'd still be an ugly mess though, since
I suspect you'd have to introduce a whole structure of varchar2
functions/operators paralleling text.  For example, what is Oracle's
handling of || ?  AFAICS they can't be standards compliant there,
which means you need a varchar2-specific nonstrict implementation
of ||, and then to make that work the way Oracle users would expect,
varchar2-ness rather than text-ness would have to propagate through
anything else that might be done to a column before it reaches the ||.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Fixing Grittner's planner issues
Next
From: Bruce Momjian
Date:
Subject: Re: vacuumdb --freeze