On Thu, Feb 19, 2009 at 02:02:06PM -0500, Tom Lane wrote:
> 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 seems like the most horrible failure of encapsulation. I don't
know the code well enough to comment, but I've already realized that I
misinterpreted the docs. They say that the type's input_function is
called for NULL values, but because it's strict this obviously doesn't
normally affect things. I was hence assuming that it was OK for the
function to return NULL for arbitrary inputs, ah well.
> 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.
[and later]
> 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 ||.
Yes, I'm somewhat prone to understatement and that's what my "fiddle"
comment was about. The only way I could see it working was to keep it
as varchar2 for a long as possible, which is why I was wondering if PG
would ever have a tendency to auto-magically convert it back to a TEXT
breaking things for the user.
> 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 ||
Didn't think about the non-strict append operator though, that's
'orrible!
-- Sam http://samason.me.uk/