Re: BLOB / CLOB support in PostgreSQL - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: BLOB / CLOB support in PostgreSQL
Date
Msg-id CADK3HH+17+uNA=oWbJVweS4BzR_wUt-0KNUAsawP_EJ7QfYtVw@mail.gmail.com
Whole thread Raw
In response to Re: BLOB / CLOB support in PostgreSQL  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: BLOB / CLOB support in PostgreSQL  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers


On Tue, 29 Sep 2020 at 14:33, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:

On 9/29/20 10:26 AM, Peter Eisentraut wrote:
> On 2020-09-28 15:46, Vladimir Sitnikov wrote:
>> The concerns to avoid "Clob maps to text" could be:
>> a) Once the behavior is implemented, it is hard to change. That is
>> applications would rely on it (and it becomes a defacto standard),
>> and it would be hard to move to the proper "text with streaming API"
>> datatype.
>> b) If we make «clob is text», then people might start using
>> update/substring APIs (which is the primary motivation for Clob)
>> without realizing there’s full value update behind the scenes.
>> Currently, they can use setString/getString for text, and it is
>> crystal clear that the text is updated fully on every update.
>
> When we added TOAST, we made the explicit decision to not add a "LONG"
> type but instead have the toasting mechanism transparent in all
> variable-length types.  And that turned out to be a very successful
> decision, because it allows this system to be used by all data types,
> not only one or two hardcoded ones.  Therefore, I'm very strongly of
> the opinion that if a streaming system of the sort you allude to were
> added, it would also be added transparently into the TOAST system.
>
> The JDBC spec says
>
> """
> An implementation of a Blob, Clob or NClob object may either be
> locator based or result in the object being fully materialized on the
> client.
>
> By default, a JDBC driver should implement the Blob, Clob and NClob
> interfaces using the appropriate locator type. An application does not
> deal directly with the locator types that are defined in SQL.
> """
>
> (A "locator" in SQL is basically what you might call a streaming handle.)
>
> So yes, this encourages the implementation of locators.  But it also
> specifies that if you don't have locators, you can implement this
> using non-large-object types.
>
>

So if I read this correctly what I have proposed is completely kosher
according to the spec - it's the "fully materialized on the client"
variant, just like the MySQL and MSSQL drivers.


I haven't really looked at MySQL or MSSQL but do they implement the full CLOB API ?
We would need to implement the full API.

BTW, just because it adheres to the spec doesn't seem to hold water in the PostgreSQL project. Just sayin'

Dave

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: BLOB / CLOB support in PostgreSQL
Next
From: Andrew Dunstan
Date:
Subject: Re: BLOB / CLOB support in PostgreSQL