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

From Dave Cramer
Subject Re: BLOB / CLOB support in PostgreSQL
Date
Msg-id CADK3HHKyUKB=9sJ7LwA4dnzkJLkGCUt9OoXP1y+EJ10AqRH_xg@mail.gmail.com
Whole thread Raw
In response to Re: BLOB / CLOB support in PostgreSQL  (Andy Fan <zhihui.fan1213@gmail.com>)
List pgsql-hackers


On Mon, 28 Sep 2020 at 20:08, Andy Fan <zhihui.fan1213@gmail.com> wrote:


On Tue, Sep 29, 2020 at 5:22 AM Vladimir Sitnikov <sitnikov.vladimir@gmail.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

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: OpenSSL 3.0.0 compatibility
Next
From: Ajin Cherian
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions