Subject: Re: Mysql -> Postgresql pitfalls
From: Rod Taylor <rbt@rbt.ca>
To: "scott.marlowe" <scott.marlowe@ihs.com>
Cc: "Chad N. Tindel" <chad@tindel.net>, Josh Berkus <josh@agliodbs.com>,
	PostgreSQL Docs <pgsql-docs@postgresql.org>
In-Reply-To: <Pine.LNX.4.33.0308041323060.10821-100000@css120.ihs.com>
References: <Pine.LNX.4.33.0308041323060.10821-100000@css120.ihs.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-tH2h0Pt62mdl6ub80Ho8"
Message-Id: <1060030888.91190.22.camel@jester>
Mime-Version: 1.0
Date: Mon, 04 Aug 2003 17:01:29 -0400

--=-tH2h0Pt62mdl6ub80Ho8
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

> speak in the \copy command.  I.e. you wouldn't use inserts to load your=
=20
> data, you'd use a bulk copy, which bypassess all the serial / IDENTITY=20
> stuff.  Basically, with the IDENTITY type, if you try to insert a value,=
=20

COPY enforces everything that insert does.  It's simply a little quicker
than insert due to a different string parsing method and avoiding places
that are for advanced features (subselects, functions, etc.).

A default is still applied if the column has not been provided.=20
Likewise, triggers (constraint triggers anyway) still run.

Bumping the start value for an IDENTITY is simple:

CREATE TABLE tab (
 col integer GENERATED ALWAYS AS IDENTITY(START WITH 42)
);

I suppose we'll need a GUC so that GENERATED ALWAYS isn't actually
always -- just usually.

--=-tH2h0Pt62mdl6ub80Ho8
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQA/Lsmn6DETLow6vwwRAsNYAKCDY3vbw6TT43csMB7ygg6RaQ074gCeO+m9
h5xvVX6y3WhJXJ+R4VczcvY=
=ADq9
-----END PGP SIGNATURE-----

--=-tH2h0Pt62mdl6ub80Ho8--