From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Aaron Colflesh <aaron(at)synthesyssolutions(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Allowing Custom Fields |
Date: | 2006-01-27 16:40:35 |
Message-ID: | 20060127164035.GA27211@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Jan 27, 2006 at 10:25:00 -0600,
Aaron Colflesh <aaron(at)synthesyssolutions(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Uwe C. Schroeder | 2006-01-27 16:42:06 | Re: Allowing Custom Fields |
Previous Message | Aaron Colflesh | 2006-01-27 16:40:05 | Re: Allowing Custom Fields |