Thread: pgsql/ ontrib/spi/autoinc.c oc/src/sgml/dataty ...

CVSROOT:    /home/projects/pgsql/cvsroot
Module name:    pgsql
Changes by:    tgl@hub.org    01/08/16 16:38:56

Modified files:
    contrib/spi    : autoinc.c
    doc/src/sgml   : datatype.sgml
    doc/src/sgml/ref: create_sequence.sgml
    src/backend/commands: creatinh.c sequence.c view.c
    src/backend/nodes: copyfuncs.c equalfuncs.c outfuncs.c
    src/backend/parser: analyze.c gram.y keywords.c
    src/bin/pg_dump: pg_dump.c
    src/include/catalog: catversion.h pg_proc.h
    src/include/commands: sequence.h
    src/include/nodes: parsenodes.h
    src/interfaces/ecpg/preproc: keywords.c preproc.y
    src/test/regress/expected: rules.out
    src/test/regress: regress.c

Log message:
    Sequences are now based on int8, not int4, arithmetic.  SERIAL pseudo-type
    has an alias SERIAL4 and a sister SERIAL8.  SERIAL8 is just the same
    except the created column is type int8 not int4.
    initdb forced.  Note this also breaks any chance of pg_upgrade from 7.1,
    unless we hack up pg_upgrade to drop and recreate sequences.  (Which is
    not out of the question, but I don't wanna do it.)

> Log message:
>     Sequences are now based on int8, not int4, arithmetic.  SERIAL pseudo-type
>     has an alias SERIAL4 and a sister SERIAL8.  SERIAL8 is just the same
>     except the created column is type int8 not int4.
>     initdb forced.  Note this also breaks any chance of pg_upgrade from 7.1,
>     unless we hack up pg_upgrade to drop and recreate sequences.  (Which is
>     not out of the question, but I don't wanna do it.)

We have to get some oid filename mapping into pg_upgrade too for it to
work.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> We have to get some oid filename mapping into pg_upgrade too for it to
> work.

Good point.  In theory you could hack the pg_class.relfilenode column
to match the older database, but we have no code to do it.

BTW, I'm also suspicious about whether pg_class.oid !=
pg_class.relfilenode actually works.  I think there may be some places
where we are using one but should be using the other.  I have a TODO
item to grovel through the code and make sure this is all okay, but it's
not going to get to the top of the queue until there's a pressing reason
to do it.

Oh well, another cycle with no pg_upgrade :-(

            regards, tom lane

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > We have to get some oid filename mapping into pg_upgrade too for it to
> > work.
>
> Good point.  In theory you could hack the pg_class.relfilenode column
> to match the older database, but we have no code to do it.
>
> BTW, I'm also suspicious about whether pg_class.oid !=
> pg_class.relfilenode actually works.  I think there may be some places
> where we are using one but should be using the other.  I have a TODO
> item to grovel through the code and make sure this is all okay, but it's
> not going to get to the top of the queue until there's a pressing reason
> to do it.
>
> Oh well, another cycle with no pg_upgrade :-(

I tried to talk a company that is new to PostgreSQL support into doing
it.  :-)

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026