| 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: | Whole Thread | Raw Message | 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 |