Re: [PERFORM] <empty string> Vs NULL

From: Marc Mamin <M(dot)Mamin(at)intershop(dot)de>
To: sridhar bamandlapally <sridhar(dot)bn1(at)gmail(dot)com>
Cc: pgsql-admin <pgsql-admin(at)postgresql(dot)org>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [PERFORM] <empty string> Vs NULL
Date: 2015-02-09 12:42:29
Message-ID: B6F6FD62F2624C4C9916AC0175D56D8828B5B4AA@jenmbs01.ad.intershop.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-performance


>>Hi
>>
>>2015-02-09 12:22 GMT+01:00 sridhar bamandlapally <sridhar(dot)bn1(at)gmail(dot)com>:
>>
>> Hi All
>>
>> We are testing our Oracle compatible business applications on PostgreSQL database,
>>
>> the issue we are facing is <empty string> Vs NULL
>>
>> In Oracle '' (<empty string>) and NULL are treated as NULL
>>
>> but, in PostgreSQL '' <empty string> not treated as NULL
>>
>> I need some implicit way in PostgreSQL where ''<empty string> can be treated as NULL

>It is not possible in PostgreSQL. PostgreSQL respects ANSI SQL standard - Oracle not.
>
>Regards
>
>Pavel
>
>p.s. theoretically you can overwrite a type operators to support Oracle behave, but you should not be sure about unexpected negative side effects.

A clean way would be to disallow empty strings on the PG side.
This is somewhat combersome depending on how dynamic your model is
and add some last on your db though.

ALTER TABLE tablename ADD CONSTRAINT tablename_not_empty_ck
CHECK (false= (colname1 IS NULL OR colname2 IS NULL OR colname3 IS NULL ...) IS NULL)

-- and to ensure compatibility with your app or migration:

CREATE OR REPLACE FUNCTION tablename_setnull_trf()
RETURNS trigger AS
$BODY$
BEGIN
-- for all *string* columns
NEW.colname1 = NULLIF (colname1,'');
NEW.colname2 = NULLIF (colname2,'');
NEW.colname3 = NULLIF (colname3,'');
RETURN NEW;
END;
$BODY$

CREATE TRIGGER tablename_setnull_tr
BEFORE INSERT OR UPDATE
ON tablename
FOR EACH ROW
EXECUTE PROCEDURE tablename_setnull_trf();

You can query the pg catalog to generate all required statements.
A possible issue is the order in which triggers are fired, when more than one exist for a given table:
"If more than one trigger is defined for the same event on the same relation, the triggers will be fired in alphabetical order by trigger name"
( http://www.postgresql.org/docs/9.3/static/trigger-definition.html )

regards,

Marc Mamin

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Nicolas Paris 2015-02-09 12:45:38 Re: Change postgresql encoding
Previous Message Nikolas Everett 2015-02-09 12:36:13 Re: <empty string> Vs NULL

Browse pgsql-performance by date

  From Date Subject
Next Message Geoff Winkless 2015-02-09 12:48:51 Re: [ADMIN] <empty string> Vs NULL
Previous Message Nikolas Everett 2015-02-09 12:36:13 Re: <empty string> Vs NULL