Re: Automatically parsing in-line composite types

From: Mitar <mmitar(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: f(dot)venchiarutti(at)ocado(dot)com, Dave Cramer <pg(at)fastcrypt(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Automatically parsing in-line composite types
Date: 2019-10-30 23:05:34
Message-ID: CAKLmikO=yB5hGGvB6AdyQpzFH9h9L=2=1MoDshAUpEZ=TnqhiA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi!

On Wed, Oct 30, 2019 at 3:06 PM Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> It looks it up from the database.

Yes, this is how I started doing it in my prototype as well.

> Correct. Only declared (via CREATE TYPE) composite types will work due
> to protocol limitations.

Exactly. This is where I got stuck, so this is why I started this thread. :-(

> So if you decided to scratch in itch and create a postgres
> BSON type, no one would likely use it, since the chances of adoption
> in core are slim to none.

Yea. :-( So we get back to square one. :-(

One other approach I was investigating was developing a Babel-like
transpiler for PostgreSQL SQL, so that I could have plugins which
would convert SQL queries to automatically encode values in JSON. And
then parse it back out once results arrive. Because yes, as you note,
JSON is the only stable and supported format among all installations
there is (except for the wire format, which has limitations). So
having to map to it and back, but without developer having to think
about it, might be the best solution.

Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

In response to

Browse pgsql-general by date

  From Date Subject
Next Message M Tarkeshwar Rao 2019-10-31 05:18:45 RE: Getting following error in using cursor to fetch the records from a large table in c language
Previous Message Kevin Brannen 2019-10-30 22:50:50 RE: Upgrade procedure