On Fri, Jan 27, 2006 at 10:40:05 -0600, Aaron Colflesh <aaron@xxxxxxxxxxxxxxxxxxxxxx> wrote: > Bruno Wolff III wrote: > >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. I missed that part. There is a way to do this with one of the contrib packages (tablefunc). To use a view though, you would need to know how many columns you were going to get at the time you created the view. So this might not work for you.
