Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.postgresql > #453

Re: migration mysql to pgsql?

Show all headers | View raw

Magnus Warker, 05.06.2013 11:43:
>> ANSI
>>NO_BACKSLASH_ESCAPES
>>STRICT_ALL_TABLES
>>NO_AUTO_VALUE_ON_ZERO
>> NO_ZERO_DATE
>>NO_ZERO_IN_DATE
>>PIPES_AS_CONCAT
>>ONLY_FULL_GROUP_BY
>> ERROR_FOR_DIVISION_BY_ZERO
>
> ANSI means standard and this is always an advantage, but does pgsql
> use all these standards by default?

Yes.

Actually except for "NO_BACKSLASH_ESCAPES" there is no way to configure Postgres to behave differently.
You can never make it accept '2013-02-31' or '0000-00-00' as a date or run "select 1/0" without an error.

> However, I often had problems with reserved words in the past, e. g.
> with identifiers needed to build an application-level user management
> ("User", "Group", ...).

It helps if you always use plural (users, groups), but personally I don't like that either.

I never had problems finding good names that are not keywords (user_profile, group_definition).


> The main reason for thinking about quoting is that pgsql does not
> support letter cases with unquoted identifiers. This would be a great
> loss for me, since letter cases also contain information when using
> identifiers that are composed of several nouns.

Most people simply settle for underscores (more_than_one_word).

But I guess it depends on where you come from.
Using underscores and non-quoted identifiers is pretty much standard in the Oracle and Postgres world (DB2 and Informix as well, as far as I can tell).

MySQL (and SQL Server) users differ here as those systems are non-standard when it comes to case-preserving, case-sensitiv object names (at least in the default installation).

The problem with MySQL's upper/lowercase handling is, that it is not consistent across platforms and installations.

The statements:

   create table foo (id integer);
   select * from FOO;

might or might not run on a specific MySQL installation (depending on the filesystem, the default storage engine and the configuration of the storage engine)

They will *always* run on any Postgres (or Oracle) system no matter how they were configured or which operating system they use.


> That you see disadvantages with quotes conserns me, but I do see
> advantages with them...

I work with a variety of tools (and DBMS) and I have yet to see a tool that does not eventually have one or two problems with quoted identifiers.

And last but not least I simply hate typing the double quotes ;)

Back to comp.databases.postgresql | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

migration mysql to pgsql? Magnus Warker <warker@mailinator.com> - 2013-06-05 08:46 +0200
  Re: migration mysql to pgsql? Harry Tuttle <SOZRBLNTLEEE@spammotel.com> - 2013-06-05 10:09 +0200
    Re: migration mysql to pgsql? Magnus Warker <warker@mailinator.com> - 2013-06-05 11:43 +0200
      Re: migration mysql to pgsql? Harry Tuttle <SOZRBLNTLEEE@spammotel.com> - 2013-06-05 11:59 +0200
        Re: migration mysql to pgsql? Magnus Warker <warker@mailinator.com> - 2013-06-05 13:06 +0200
          Re: migration mysql to pgsql? Robert Klemme <shortcutter@googlemail.com> - 2013-06-05 21:30 +0200
      Re: migration mysql to pgsql? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2013-06-05 10:59 +0000
  Re: migration mysql to pgsql? Walter Hurry <walterhurry@lavabit.com> - 2013-06-07 21:52 +0000
    Re: migration mysql to pgsql? gargoyle60 <gargoyle60@example.invalid> - 2013-06-08 09:12 +0100
  Re: migration mysql to pgsql? johannes falcone <visphatesjava@gmail.com> - 2013-06-18 12:03 -0700

csiph-web