More detail, as suggested. I have an existing table in an app, along the lines of: >> >> CREATE TABLE foo ( >> name text, >> address text, >> some_numeric_info integer, >> <a bunch of additional fields here> >> ); >>
I essentially need another table CREATE TABLE foo_printing_options ( field_name text, print_order int not null, suppress boolean not null, <a couple additional options here> ); The values of field_name in foo_printing_options would be the individual field names in foo (i.e. name, address, etc). foo_printing_options would be available to the user via the app to allow them to specify report layout. My question, then, is if it considered acceptable practice to, instead of having field_name in the secondary table, have a foreign key reference back to the field definition in the meta-data. This would allow the app to be less sensitive to schema changes (fairly common). Is linking to the metadata from the app tables directly bad? Unsafe? Ok? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
