On Fri, Jan 27, 2006 at 10:25:00 -0600, Aaron Colflesh <aaron@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > #2 would seem to be the simplest except I'm really not too keen on the > idea of manipulating a table like that on the fly (even though I did > proof of concept it and it seems to be simple enough to be fairly safe > if adequate checks for entries on table B are put into the system). Does > anyone know of a 3rd way of doing it? It seems like this shouldn't be an > all that uncommon task, so I'm hoping there is some slick way of maybe > putting together a function or view to return data rows with a flexible > field layout. So far all the in-db tricks I've come up with have > required me to know what the field names were to generate the final > query anyway, so they don't really gain me anything. Couldn't you let the user creating a view joining A and B?
