Re: WIP: hooking parser

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-16 14:48:45
Message-ID: 20090216144845.GW32672@frubble.xen.chris-lamb.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
> 2009/2/16 Sam Mason <sam(at)samason(dot)me(dot)uk>:
> > On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
> >> attachment contains module that transform every empty string to null.
> >
> > Why would anyone ever want to do this? This would appear to break all
> > sorts of things in very non-obvious ways:
>
> I agree, so this behave is strange - but Oracle does it.
>
> so normal query in Oracle for empty value looks like
>
> select * from people where surname is null;
>
> and some application expect transformation from '' to null.
>
> http://www.thunderguy.com/semicolon/2003/04/26/oracle-empty-string-null/

that's pretty grim!

<rant>
I'd agree with the comment saying "A string variable that can't be
set empty is like a number variable that can't be set zero".

Oracle have just thrown out (or, at best, rewritten) the inductive
base case for strings. For numbers you (logically) start with a Zero
and a Succ (successor function) and model numbers as an arbitrary
number of applications of Succ to Zero ("2" is (Succ (Succ Zero))).
For strings, you start with an empty string and an append function
("hi" being (Append (Append '' \h) \i)).
</rant>

> so these modules (decode, oraemptystr) decrease differences between
> PostgreSQL and Oracle.

wouldn't it be better/easier to extend something like pgpool to
transform Oracle style SQL code to PG style code? You'd certainly
be able to get it more complete in reasonable amounts of time, but
performance would suffer when you went to look up table definitions to
check the types of various things.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-02-16 14:53:51 Re: SE-PostgreSQL and row level security
Previous Message Greg Stark 2009-02-16 14:35:33 Re: SE-PostgreSQL and row level security