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?
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 |