| From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BLOB / CLOB support in PostgreSQL |
| Date: | 2020-09-29 20:48:24 |
| Message-ID: | CAB=Je-GFPY1+Az5TgMRsWacb_Fdpg+4FZ4ua9-2tfLU3xaRv0g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-jdbc |
Andrew>It needs to contain a substantial implementation plan
Here's an implementation plan, again, quoted from the very same mail:
Vladimir>Of course both variations above fail to support streaming
Vladimir> (as in "need to process all the contents in order to get the last
character"), so it might be better to use
Vladimir>"prefix that specifies encoding + 'index block' (that specifies
offsets for each 1M characters) + encoded string".
It does describe the data structure.
Andrew>what APIS
I believe it does not matter much.
However, it might be similar to the existing LO APIs, except the indices
are in characters rather than bytes.
Andrew>protocol changes
None.
Andrew>and so on
Well, it looks like I had everything you mentioned in the very first email.
Vladimir
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-09-29 22:13:46 | Why does PostgresNode.pm set such a low value of max_wal_senders? |
| Previous Message | David Rowley | 2020-09-29 20:39:34 | Re: Planner making bad choice in alternative subplan decision |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tsunakawa.takay@fujitsu.com | 2020-09-30 02:31:40 | RE: BLOB / CLOB support in PostgreSQL |
| Previous Message | Andrew Dunstan | 2020-09-29 20:16:14 | Re: BLOB / CLOB support in PostgreSQL |