Steve Baldwin writes:
> 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 y
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
com
> CREATE TYPE po_dates AS (
> po_isssued_datetimestamptz,
> 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?
On Fri, Nov 08, 2019 at 12:12:59PM -0800, Adrian Klaver wrote:
> On 11/8/19 11:57 AM, Michael Lewis wrote:
> > You certainly could choose to store as??tstzrange, but why not use two
> > fields?
> >
> > https://www.postgresql.org/docs/current/rangetypes.html
>
> I would lean more to a composite ty
On 11/8/19 11:57 AM, Michael Lewis wrote:
You certainly could choose to store as tstzrange, but why not use two
fields?
https://www.postgresql.org/docs/current/rangetypes.html
I would lean more to a composite type:
https://www.postgresql.org/docs/11/rowtypes.html
Range types are built aroun
You certainly could choose to store as tstzrange, but why not use two
fields?
https://www.postgresql.org/docs/current/rangetypes.html
I need to create a table to store terms and conditions for purchase
orders.
Some of the attributes of a PO include payment terms. Quite often these will
be 2 periods associated with these, the first is a period on which if you
pay, you receive a discount, and the 2nd is when payment is due with no
