Re: MySQL search query is not executing in Postgres DB

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Don Baccus <dhogaza(at)pacifier(dot)com>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, Rob Wultsch <wultsch(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: MySQL search query is not executing in Postgres DB
Date: 2012-02-18 22:55:43
Message-ID: m2ty2ng39s.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Don Baccus <dhogaza(at)pacifier(dot)com> writes:
>> A hierarchy like the following is perfectly logical:
>> - 0000 to 0999 :: Cash accounts [1]
>
> Your example is actually a good argument for storing account ids as
> text, because '0000' like '0%' *will* match.

FWIW, I too think that if you want to process your integers as text for
some operations (LIKE) and as integer for some others, you'd better do
the casting explicitly.

In the worked-out example Christopher has been proposing, just alter the
column type to text and be done, I can't see summing up or whatever int
arithmetic usage being done on those general ledger account numbers. Use
a domain (well a CHECK constraint really) to tight things down.

As for lpad(), that's a function working on text that returns text, so
having a variant that accepts integers would not be confusing. Then
again, why aren't you using to_char() if processing integers?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

PS: having worked on telephone number prefix indexing and processing
them as text, I might have a biased opinion. You don't add up phone
numbers, though, do you?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2012-02-18 23:01:37 Re: Notes about fixing regexes and UTF-8 (yet again)
Previous Message Don Baccus 2012-02-18 22:34:24 Re: MySQL search query is not executing in Postgres DB