Re: BLOB / CLOB support in PostgreSQL

From: Dave Cramer <davecramer(at)postgres(dot)rocks>
To: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
Cc: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: BLOB / CLOB support in PostgreSQL
Date: 2020-09-29 11:00:15
Message-ID: CADK3HHKyUKB=9sJ7LwA4dnzkJLkGCUt9OoXP1y+EJ10AqRH_xg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

On Mon, 28 Sep 2020 at 20:08, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:

>
>
> On Tue, Sep 29, 2020 at 5:22 AM Vladimir Sitnikov <
> sitnikov(dot)vladimir(at)gmail(dot)com> wrote:
>
>> >100% compatible with the MySQL
>>
>> It is hardly a justification for a feature or for a change request.
>>
>> Vladimir
>>
>
I would have to agree. This argument alone has not swayed discussions in
the past.

>
>>
> Glad to see this topic.
>
> The obviously different opinion for this feature is based on if we need a
> "perfect" solution
> or a "OK-to-most-user cases" solution.
>
> As for PG core developers, I'm +1 with "pg have their own serious
> problems" , and
> we are lacking the resources to handle everything well. However, "serious
> problems"
> to different people may be different.
>
> As a rare experienced Java developer, looks raise "NotImplemented" error
> for some
> unimplemented APIs will not make the maintenance work hard, that probably
> not common
> used APIs. Not fully supported API should be better than fully not
> supported APIs at all.
>
> I don't agree with this statement. Currently the largest source of
problems with CLOB not being implemented is from hibernate which chose to
not follow the spec and for some reason fails if we throw a not implemented
(which is allowed by the spec). If we now implement something which only
partially implements the API I can imagine others failing in other ways.
Honestly I have no idea but what is the point of he spec if we don't adhere
to it?

> As an Oracle DBA before, I do see users need CLOB/BLOB some time but for
> most of them,
> they just want to save/get big stuff. This case in Oracle may be more
> outstanding because of
> the max length of varchar2 is too low.
>
> It is rare to see people writing JDBC now. It is much more likely they are
using JPA or hibernate. Getting around this is rather trivial simply by
using @Type(org.hibernate.type.TextType)

> When come to the JDBC standard
>
> JDBC Spec> * All methods on the <code>Clob</code> interface must be fully
> implemented if the
> JDBC Spec> * JDBC driver supports the data type.
>
> What would be the sense behind this? This is not reasonable based on
> limited experience.
>

The sense about this is that others writing code above it expect everything
to be implemented. If they aren't then things fail.

As mentioned above hibernate fails to check for not implemented and we see
the number of issues that resulted in that. Imagine what happens when we
partially implement the interface. It will be all but useless to them.

I'm not currently convinced the risk/reward ratio is in our favour.

Dave

>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2020-09-29 11:37:59 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Daniel Gustafsson 2020-09-29 10:25:05 Re: OpenSSL 3.0.0 compatibility

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Cramer 2020-09-29 12:31:54 [pgjdbc/pgjdbc] 239324: fix: handle smallserial correctly fixes #1897 (#1899)
Previous Message Pavel Stehule 2020-09-29 06:23:20 Re: Support for OUT parameters in procedures