From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: hooking parser |
Date: | 2009-02-19 18:29:25 |
Message-ID: | 20090219182925.GY32672@frubble.xen.chris-lamb.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
--
Sam http://samason.me.uk/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-02-19 18:38:51 | Re: Fixing Grittner's planner issues |
Previous Message | Bruce Momjian | 2009-02-19 18:24:52 | Re: vacuumdb --freeze |