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
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 |