On Thu, 27 Jan 2005 12:43:56 -0500, Alexandre Leclerc
<[EMAIL PROTECTED]> wrote:
> On Thu, 27 Jan 2005 17:27:40 +0100, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> > On Thu, 27 Jan 2005 10:23:34 -0500, Alexandre Leclerc
> > <[EMAIL PROTECTED]> wrote:
> > > Here a normal listing of design.product_department_time:
> > > product_id | department_id | req_time
> > > ------------+---------------+----------
> > > 906 | A | 3000
> > > 906 | C | 3000
> > > 906 | D | 1935
> > > 907 | A | 1500
> > > 907 | C | 1500
> > > 907 | D | 4575
> > > 924 | A | 6000
> > > 924 | C | 1575
> >
> > Well, I did something like this recently; it can be done though
> > maybe not very efficiently...
> >
> > Unfortunately we will need a rowtype with all the departaments:
> > CREATE DOMAIN departaments AS (a int, b int, c int, d int, ...);
> Thank you for this help Dawid, I'll have to take some time to look at
> this suggestion. If I must create a domain with all the departments
> I'll have a problem because the user is creating and deleting
> departments as it pleases him.
>
> Any counter-ideas?
I have exactly the same problem with my proposal [1]
I just wish there would be some "native" rows-to-columns
aggregate.
The other approach I used was something like this:
SELECT product_id, a, b, c FROM
(SELECT product_id, a FROM pdt) AS a FULL OUTER JOIN USING(product_id)
(SELECT product_id, b FROM pdt) AS b FULL OUTER JOIN USING(product_id)
(SELECT product_id, c FROM pdt) AS c;
...or similar (I'm typing from memory ;)). Anyway it was good for getting
whole table, but performance well, wasn't the gratest. ;)).
Regards,
Dawid
[1]: I was thinking about a trigger on a "departaments" table,
and then recreating the aggregate and view as needed, but
it isn't the kind of dynamic I had in mind. ;)
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
