Thread: Best method to display table information in predefined formats

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.

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
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com

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

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

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