Re: Example 43.6. A PL/pgSQL Trigger Function for Maintaining a Summary Table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Maxim Yablokov <m(dot)yablokov(at)postgrespro(dot)ru>, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: Example 43.6. A PL/pgSQL Trigger Function for Maintaining a Summary Table
Date: 2023-10-28 02:16:54
Message-ID: 1688333.1698459414@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> Thanks, I'll await pushing and backpatching if Tom who committed it has
> insights into whether it was missed or if it indeed serves a purpose.

Hey, I just pushed that for somebody else, I don't claim authorship ;-)

It seems clear that the example intends to show a star-schema database
where the fact table refers to various dimension tables. But it's
incomplete --- there's no foreign-key constraint on time_key, and
even less infrastructure for product_key or store_key. I don't
have the cited book either, so I don't know how complete the original
example was. Perhaps the bit in the trigger function about forbidding
updates to time_key has something to do with that model.

Anyway, I don't see any reason to object to this patch. The extra
table isn't adding much. My only thought is would it make sense to
change time_key to be a timestamp or timestamptz value?

regards, tom lane

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Laurenz Albe 2023-10-28 08:53:58 Re: unnest multirange, returned order
Previous Message Bruce Momjian 2023-10-28 01:12:18 Re: Typo in docs for "recovery_init_sync_method" parameter.