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

From Sam Mason
Subject Re: WIP: hooking parser
Date
Msg-id 20090219182925.GY32672@frubble.xen.chris-lamb.co.uk
Whole thread Raw
In response to Re: WIP: hooking parser  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP: hooking parser  (Kenneth Marshall <ktm@rice.edu>)
Re: WIP: hooking parser  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > I'd be quite interested to support some kind of hook to deal with this 
> > Oracle null issue.  It would be a great help for porting projects.
> 
> > However, doing this properly is probably more complex and needs further 
> > thought.  I'd suggest writing a type of regression test first for Oracle 
> > null behavior and then evaluating any kind of hook or hack against that.
> 
> 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?  It would be a bit
of a fiddle going through all the operators and functions making sure
that versions existed to cast things back again but seems possible.

Not sure how fragile user code would be with it though, I'm mainly
worried about it trying to convert things back to TEXT automatically and
the resulting change in semantics.  Any ideas about good ways to go?

--  Sam  http://samason.me.uk/


pgsql-hackers by date:

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