Re: Sequence names have 64 character limit?

Once more, thanks!

Of course, using SERIAL is the ideal method, but I can't have the programs
in question fail because someone neglected to set up a dependency. Other
people may be slobs, but I'm afraid I can't be. In fact, my very first
attempt to use pg_get_serial_sequence(table_name, column_name) returned a
NULL result, which tells me that it's a reality I have to deal with.

I'll stick with the column default parsing method...

Adrian, Jerry - thanks very much for the info.

Carlo

-----Original Message-----
From: Adrian Klaver [mailto:adrian(dot)klaver(at)gmail(dot)com]
Sent: March 31, 2011 6:15 PM
To: Carlo Stonebanks
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Sequence names have 64 character limit?

On 03/31/2011 02:47 PM, Carlo Stonebanks wrote:
> Thanks Adrian and Jerry.
>
> Technically, the best way to know which sequence a column is dependent on
is
> to actually query for it. I have functions which query
> information_schema.columns and run a regex_replace to extract the sequence
> name from the defaulting nextval() expression. This is better than
demanding
> that sequence names are predictable, but I wonder if there isn't a better
> query to run that doesn't require parsing texts? Obviously PG knows about
> the sequence's relation, probably via a dependency that finds it by
> rendering the text to regclass to an OID... but this stuff makes me
nervous.
>
> So, a query that returns the sequence name (as text, you can cast to
> regclass!) associated with a particular column, that would return NUL if
> there was none... I don't suppose anyone has written such a query
before...?
>
> Yes, I'd write a function around it!
>
> Thanks again,
>
> Carlo

Well in 8.2+ for sequences created by the SERIAL datatype there is the
function:
pg_get_serial_sequence(table_name, column_name)

The benefit of using SERIAL is that it sets up a dependency.
If you specify the sequence via CREATE SEQUENCE then AFAIK you are left
looking up the default and parsing it.

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com