On Fri, Jan 27, 2006 at 10:40:05 -0600,
Aaron Colflesh <aaron@synthesyssolutions.com> wrote:
> Bruno Wolff III wrote:
> >On Fri, Jan 27, 2006 at 10:25:00 -0600,
> > Aaron Colflesh <aaron@synthesyssolutions.com> 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.