On 4/8/20 8:39 AM, Mark Bannister wrote:
>
> 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.
Which is correct filling in fields, populating a view or both?
>
> --
>
> Mark B
>
--
Adrian Klaver
adrian.klaver@aklaver.com
