Re: Getting the currently used sequence for a SERIAL column

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hanne Moa <hanne(dot)moa(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Getting the currently used sequence for a SERIAL column
Date: 2016-10-18 13:20:39
Message-ID: 19010.1476796839@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hanne Moa <hanne(dot)moa(at)gmail(dot)com> writes:
> Until now we've been using pg_get_serial_sequence() to discover
> which sequence is in use, but can no longer do so due to two tables
> needing to share the same sequence (prior to being properly merged. No
> duplicate values, luckily). For one of the tables,
> pg_get_serial_sequence() won't be returning anything useful since it
> tracks which table *owns* a sequence and not which sequence is used
> by which column.

> The necessary information seems to be in the table
> "information_schema.columns", in "column_default". Is this to be
> regarded as internal API or is it safe to use this to find the correct
> sequence? It works in all cases and on all the version of postgres
> that are relevant to us. The production system is currently running
> 9.3 (I'm pining for 9.5...)

> Furthermore, what's stored in the column seems to be a string of the
> format "nextval('sequencename'::regclass)". Is there a function to
> parse this, to return just the sequence name, or will the sequence
> name always be without for instance a schema name so that a naive
> parser of our own will do? Googling found no candidates.

Personally, I'd try looking in pg_depend to see if the column's default
expression has a dependency on a relation of type sequence. That avoids
all the fun of parsing the expression and turns it into a simple SQL
join problem.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Kellerer 2016-10-18 13:45:22 Re: Getting the currently used sequence for a SERIAL column
Previous Message Andreas Joseph Krogh 2016-10-18 13:06:11 Re: pg_upgrade not able to cope with pg_largeobject being in a different tablespace