Re: Storing a time interval

From: Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com>
To: Michael Lewis <mlewis(at)entrata(dot)com>
Cc: stan <stanb(at)panix(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Storing a time interval
Date: 2019-11-08 21:20:26
Message-ID: CAKE1Aib_+NhhD69Pdej-YOCuetq5NeKYAGc67z-Pruu24AZTmw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I agree with Michael. Another consideration is how the composite type is
going to be handled in the DB layer of your processing code (e.g. node,
python, ...). In the scenario you described it seems unlikely you will be
either having multiple columns of that type on your PO table, or using that
composite type on a different table, so apart from the 'interest' factor,
I'm not seeing any practical benefit. Composite types are also slightly
painful in the change they bring to the way you reference them. For example
typically you need to surround the outer column in brackets - e.g.
(dates).discount_last_date. If you are using an ORM library, does it know
how to deal with that?

Steve

On Sat, Nov 9, 2019 at 8:11 AM Michael Lewis <mlewis(at)entrata(dot)com> wrote:

> CREATE TYPE po_dates AS (
>> po_isssued_date timestamptz,
>> discount_last_date timestamptz,
>> net_date timestamptz
>> );
>>
>
> What advantage does combining these three values into a custom composite
> type give you rather than just storing directly? Are you going to reuse
> this po_dates type on many tables?
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Israel Brewster 2019-11-08 23:27:51 Merge sort/postgis performance tweaking?
Previous Message Michael Lewis 2019-11-08 21:10:36 Re: Storing a time interval