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
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 |