Re: Best way to populate nested composite type from JSON`

From: Chris Travers <chris(dot)travers(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Best way to populate nested composite type from JSON`
Date: 2013-09-13 00:25:26
Message-ID: CAKt_Zft3nUSeTy3eOoGU89d=ONwKD2axqLwJOVSSkdQBiWOTdw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Sep 12, 2013 at 8:47 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

>
>
> Can we see a hypothetical example? json best practices for me are to
> use standard tables and than serialize/deserialize json as it goes
> through the door and not use nested composite types in your actual
> table definitions. I think it should all fit if you do it right: you
> json_[each/array_elements] the wrapping json then insert it into
> un-nested actual tables. If you must have a final destination as a
> nested composite, I think at the worst case you might have to make
> some transition composites...
>

Here is what I am thinking (roughly):

CREATE TYPE trans_line (
description text,
amount numeric,
account_id int
);

CREATE TYPE journal_entry (
reference text,
description text,
post_date date,
lines trans_line[]
);

CREATE FUNCTION save(journal_entry) RETURNS .... LANGUAGE PLPGSQL AS
$$
....
$$;

What I would like to be able to do is accept that complex data type in as a
JSON object and convert it to the record format. The data could then be
broken apart, inserted checked for validity (make sure the transaction is
balanced etc) and then inserted into the correct tables. My idea was to
create a json::journal_entry cast and use that. Otherwise I get to have
fun with row and array constructors and system tables.

However one can't pass nested JSON objects through json_populate_record().
My question is basically how to get around that.

Best wishes,
Chris Travers

>
> merlin
>

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more.shtml

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2013-09-13 06:53:57 Re: Risk of set system wise statement_timeout
Previous Message BladeOfLight16 2013-09-12 23:58:11 Re: Sum of columns