Clash of the Backends leaves Developer stunned
So I’ve heard from a number of Omnis/SQL Gurus on the subject of “Generic SQL” and Backends.
One told me to stick to the Standard SQL as much as possible for portability. Other amongst the knowing tell me that there are multiple standards and besides the backends give differing results for the same commands, and that trying to handle multiple backends is a pain.
So my very general question is this: Should one tell oneself that they are trying to stick to the standard? Should one try at all?
I just had the case where I need to “cast” my numeric field to text so that I can do a LIKE comparison in a Where Clause. I was given two ways of casting… one is to write cast() in front of the column name in question, and the other is Postgres’s way where you say name::text to cast it to text. I’m using a Postgres server as I develop, and it does not recognize the first method, only it’s own method.
So as I sit here I’m faced with “Have bugs now”. I either can run in dev mode with this Postgres server and do things it’s way or face bugs now. Weird. I’d have to fork now for differing backends and I can see as Alex said that “That is a pain”. I can see that. I don’t want that.
The clientele I’ll be aiming at in my “practice” when I’ve learnt enough to “get out there” will be smaller companies, because I work alone. I believe that smaller means “not as stuck on what backend they want to use” as larger corporations who may already have a standard they stick to. So I am MORE OK with just Postgres than if I were targeting the very large companies.
What to tell myself ? Which way to develop in the here and now ? I don’t want to fork all over the place for different DAMS and backends. I can barely do what I’m doing, I mean it’s a hard learning curve as is. What to do brothers and sisters in arms ? What to do?