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?
I have yet to find a way to make a query that will take the individual
row values of one table and make them appear to be columns (either by
themselves or as part of a join to another table). If someone can tell
me how to do that, then yes a view would be ideal.