Sounds like you should design a function to call custom views based on what is needed.Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------From: Mark Bannister <mark(at)injection-moldings(dot)com> Date: 4/8/20 11:39 (GMT-05:00) To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org Subject: Re: Best method to display table information in predefined formats
On 4/8/2020 10:28 AM, Adrian Klaver
wrote:
On
4/8/20 6:39 AM, Mark Bannister wrote:
I am converting an application to
postgresql. On feature I have is functions that return custom
displays of a table row. For instance the company display
function might display just the company name, or company name +
other information. It may also call other displays, for
instance, address or phone numbers which in turn have display
functions. What is returned depends on context and other
parameters. The return value is typically displayed the ui in
views of the table. For instance a listing of purchase orders
could list PO number, and use the company display function to
list the company information. Depending on the display it could
show just the company name or complete details of the company
(in the context of the PO).
There is also a generic function that will display per-defined
default fields so that a custom function is not required for
each table.
What is the best way to reproduce this and take advantage of
postgresql caching? These functions can be called a lot.
I am not understanding what you are after, especially this part:
"The return value is typically displayed the ui in views of the
table"
Are you saying the functions are called to fill in fields in a UI
form or to populate a database side view?
--
Mark B
Yes. That's correct.
--
Mark B