Home/ Questions/Q 115811
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T03:04:44+00:00

We’re migrating MySQL to PostgreSQL. I can easily audit the schema and the SQL

  • 0

We’re migrating MySQL to PostgreSQL. I can easily audit the schema and the SQL statements used throughout the (REALbasic) program. Most of the SQL is composed by building string variables.

I already know about needing to replace our use of SELECT LAST_INSERT_ID() with a SERIAL column with UNIQUE constraint.

What, if any, differences between the two which are not obviously visible in SQL statements might bite us? I’m looking for (probably subtle) assumptions about behaviour such as any differences in autocommit, need to add constraints which aren’t in MySQL etc.

I’m trying to tease out any gotchas for a couple of reasonably smart, attentive guys who aren’t gurus in either of the databases.

This is a one-way commitment so if there are major benefits we will get by adding new declarations I’d appreciate them pointing out.

Note: we’re not using any form of parameterised queries and, yes, I’ve pointed out issues with injection attacks as a required audit of the code.

Yes, for the curious, this decision was prompted by GPL issues, not that we’re averse to paying for licenses but, unfortunately, the sole REALbasic driver for MySQL was GPL. As of May 2009, Real Software have released a new Community driver which is GPL, and properly includes source. They have promised a non-GPL Enterprise driver in the near future.

I am prepared to believe that the answer might be there are no invisible monsters under the bed but thought I’d ask to be sure.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

    • select count(*) from table;

      will be slow, as it needs to read entire table. It needs workarounds if you need to count big tables often. This is needed to ensure multiversion concurrency control.

    • In the latest version (8.3) there’s no implicit cast to text, which means that for example

      select 234 like '2%';

      will throw error. You’ll need explicit cast like:

      select 234::text like '2%';

    • Update is really a delete+insert. As space used by deleted rows is not immediately freed then if you update entire table in one transaction then you’ll need double the space.

    Postgresql is a very good database, you’ll love it in no time. It has several very useful features that you’ll then miss in other, even commercial databases. For example transactional data definition language or savepoints.

    • 0