Re: WIP: hooking parser

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: hooking parser
Date: 2009-02-19 18:40:33
Message-ID: 20090219184033.GI14957@it.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 19, 2009 at 06:29:25PM +0000, Sam Mason wrote:
> On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)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?
>

Could you define a type/domain for varchar2 mapping it to varchar.
There does not seem to be anything else that needs to be done.

Cheers,
Ken

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-02-19 18:46:34 Re: Fixing Grittner's planner issues
Previous Message Tom Lane 2009-02-19 18:38:51 Re: Fixing Grittner's planner issues