PR > I just noticed that postgres has a nifty, practical way to help
PR > people migrating from systems with autoincrement fields:

DY The SQL spec also defines them. I'd rather go this way.

I suppose the SQL spec defines syntax and behaviour, not implementation.

AH > Just the usual problem of name lengths in the creation of the
AH > generator, but we could just use some sort of automatic name
AH > generation...

Yup, pretty much like we do name generation for integrity constraints

RR > a) our gbak has problem with restoring the tables containing "DEFAULT
RR > gen_id(....)" - for some reason generators are created after the
RR > tables.

Well, we could automagically define a trigger (pre, order 0) to fill
the field and avoid that area of potential problems.

RR > b) systems with autoincrement fields (at least MS Access, MS SQL
RR > Server and MySQL) do not have INSERT ... INTO ... RETURNING, but use
RR > some kind of "SELECT @@lastval" statement. So even if we provide an
RR > autoincrement type, there still will be some effort to port the
RR > application.

You are right, this issue would still be there. However, I think that
the facts that (i) most contemporary database systems offer
autoincrement, (ii) the standard defines it and (iii) our users ask
for it is a pretty good case that this functionality is beneficial to
have.

Just looking for easy ways to implement, without painting ourselves
into a corner.

Paul