Jim Nasby wrote: >Rather than trying to wedge this into a heap page, ISTM it'd be >better to use a fork. Presumably if you're storing regular tuples >that have the essential data from pg_class, pg_attribute (and maybe >pg_type).
Well, three things: - The information preferably is present in the same file with the pages; ideally upfront, but reachable through a pointer within the file is acceptable. - The information ideally is repeated at the beginning of each segment (separate file). - The information can be in tuple form, but it is acceptable (or even preferable?) to store it as a cleartext SQL CREATE TABLE statement. Not quite sure which one I'd prefer at this point. The tuple version might be easier to do machine recovery with. But in any case it needs needs database name, schema name, table name, column name, column type, NULL constraint per column. The reason putting it in a separate fork is not ideal, is that when doing recovery you might not have more than just the datafiles, and thus it is not possible to determine which fork file belongs to which datafile (the filenames might be lost, as well as the directory association). -- Stephen. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
