What to consider when moving from MySQL to PostgreSQL:

• MySQL uses nonstandard # to begin a comment line; PostgreSQL uses -- (double dash). This is the ANSI standard, and both databases understand it.
• MySQL uses single or double quote marks to quote values (e.g., WHERE name = “John”). This is not the ANSI standard for databases. PostgreSQL uses only single quote marks (e.g., WHERE name = ‘John’). Double quote marks are used to quote system identifiers, such as field names and table names (e.g., HERE “last name” = ‘Smith’).
• MySQL uses the ` (accent mark or backtick) to quote system identifiers, which is decidedly nonstandard.
• PostgreSQL is case-sensitive for string comparisons. The field “Smith” is not the same as the field “smith”. This is a big change for many users from MySQL and other small database systems, like Microsoft Access. In PostgreSQL, you can:
  —Use the correct case in your query (e.g., WHERE lname= ‘Smith’)
  —Use a conversion function, like lower() to search (e.g, WHERE lower(lname)= ‘smith’)
  —Use a case-insensitive operator: ILIKE or *~
• Database, table, field, and columns names in PostgreSQL are case-independent, unless you created them with double quote marks around their name, in which case they are case-sensitive. In MySQL, table names can be case-sensitive or not, depending on which operating system you are using.
• PostgreSQL and MySQL seem to differ most in handling of dates and in the names of functions that handle dates.
• MySQL uses C language operators for logic (e.g., ‘foo’ || ‘bar’ means ‘foo’ OR ‘bar’; ‘foo’ && ‘bar’ means ‘foo’ AND ‘bar’). This might be marginally helpful for C programmers but violates database standards and rules in a significant way. PostgreSQL, following the standard, uses || for string concatenation (e.g., ‘foo’ || ‘bar’ = ‘foobar’).