Peter Eisentraut <[EMAIL PROTECTED]> writes:
> How does one get at the missing fields.  The only way I know is 
> selecting from the sequence, but how does one work this into this 
> query?  Somehow it seems that these things should be stored in a real 
> system catalog.

Yeah.  I've occasionally toyed with the idea that sequences should be
rows in a single catalog instead of independent tables as they are now.
This would make for a much smaller disk footprint (with consequent I/O
savings) and would solve problems like the one you have.  Unfortunately
the backward-compatibility issues seem a bit daunting :-(.  It's
probably not completely impossible, but how do we preserve the existing
behavior that you can "SELECT * FROM seqname" and get the parameters?

Ideally I'd like
        SELECT * FROM seqname;          -- gets params of one sequence
        SELECT * FROM pg_sequence;      -- gets params of all sequences

One possible kluge is to make all the sequences be child tables of a
pg_sequence catalog that exists only to be their inheritance parent.
This seems pretty ugly from a performance point of view though.
Selecting from pg_sequence would be really expensive if you have a lot
of sequences, and there wouldn't be any opportunity for reducing the
disk footprint.

(Thinks a bit...)  Maybe it would work for pg_sequence to be a real
catalog with a row per sequence, and we also create a view named after
the sequence that simply selects from pg_sequence with an appropriate
WHERE condition.

Plan C would be to say that we don't need to preserve "SELECT * FROM
seqname", but I'll bet there would be some hollering.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to