Re: Accessing schema data in information schema
От | Tom Lane |
---|---|
Тема | Re: Accessing schema data in information schema |
Дата | |
Msg-id | 19743.1143061914@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Accessing schema data in information schema (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Accessing schema data in information schema
Re: Accessing schema data in information schema |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> 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 likeSELECT * FROM seqname; -- gets params of one sequenceSELECT * FROM pg_sequence; -- gets paramsof 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
В списке pgsql-hackers по дате отправления: