Error displaying composite types in postgres : all values are NULL where they shouldn't be

System information:

• Operating system (distribution) and version Windows 10 Pro
• DBeaver version Issues detected from 5.2 to current 5.3.3.X
• Java version 1.8.0_77
• Additional extensions None

Connection specification:

• Database name and version postgres 10 to 11
• Driver name PostgreSQL
• Do you use tunnels or proxies (SSH, SOCKS, etc)? Yes, ssh tunnel

Describe the problem you’re observing:

When creating a table that contains a composite type (type made of two or more values), then vizualising the table, All composite values shows up as NULL

Steps to reproduce, if exist:

– create a composite type CREATE TYPE committee_id_type AS (commmittee_code varchar(6), subcommittee_number smallint); –create a table using it CREATE TABLE wrong_composite_display ( id int , comm committee_id_type ) ; – insert any data inside the table –visualize the table SELECT * FROM wrong_composite_display ;

Problem : DBeaver correctly find the composite type columns names, but display all the values as NULL, even if they are not.

Here is a screenshot, very explicit I have to explicitly select the columns of the type to see something that is not null

Note that this bug only happens when using the Grid display. When using the Text display things show up appropriately.

[Remi-C]

Hey @serge-rider and @uslss , I’m afraid bug hasn’t been solved (running DBeaver EE 6.1) 😕

I tried my best to reproduce and pinpoint the bug, and I think I have it fearly delimitated. So creating a fresh db, with the latest postgres (11): in DBeaver database navigator, make the public schema active, then

SELECT version() ;
		--PostgreSQL 11.2 (Ubuntu 11.2-1.pgdg18.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0, 64-bit

-- create schema for experiment
	DROP SCHEMA IF EXISTS composite_type_indexing CASCADE ; 
	CREATE SCHEMA IF NOT EXISTS composite_type_indexing ; 

-- creating a basic composite type 
	CREATE TYPE composite_type_indexing.bill_id_type_raw AS (
		bill_chamber  varchar(1), 
		bill_resolution_type varchar(1),
		bill_number smallint);   

-- creating a basic table using this type  
	CREATE TABLE composite_type_indexing.bills_raw (
				congress_session int NOT NULL,
				bill_id composite_type_indexing.bill_id_type_raw NOT NULL, 
				random_stuff_1 text NULL );  
	
-- inserting 3 values in the table that contains a composite type
	INSERT INTO composite_type_indexing.bills_raw
		VALUES 
			 (112,('h','r',12),'random payload')
			,(112,('h','j',1),'random payload')
			,(112,('h',NULL,1),'random payload') ;  
		
-- go in DBeaver navigator and refresh (F5)
-- Dispalry values :
	SELECT * -- shows everythign in bill_id as null
		, (bill_id).* -- when explicitely asking for composed types fields, display correct values
	FROM composite_type_indexing.bills_raw ;

Not working

Working :

At this point, it can randomly work or not (meaning, display the appropriate values in the ‘grid’ format)! Thankfully, a couple of steps allow to either correctly or incorrectly display :

• to make it work
  • make the composite_type_indexing schema active
  • set another database active
  • set the test database active (composite_type_indexing schema should still be active)
• to make it not work :
  • any schema active other than the one with type definition (regardless of the shcema of the table that uses the custom type)
  • refreshing is not enough, one has to change active db back and forth

So that looks like 2 problems:

• context problem :
  • the schema containing the type definition has to be active so that the type is correctly displayed.
  • That is a big problem, as you could very easily have a table that contains many composite types defined in many schemas.
• context update problem
  • assuming the schema containing the type definition is active, this is still not enough.
  • simply refreshing the schema/type/table is not enough
  • one as to switch the active database.
  • that’s also fairly problematic, as it opens the door to many hard-to-reproduce bugs.

To finish, I also noted two other bugs regarding composite types (not sure if they should go on another ticket). Both bugs seem to be related.

• NULL value of a subtype is not properly displayed (displayed as '' instead of NULL):
• an integer subtype with a NULL value raise an error, and all the other subtype are displayed as NULL :

The exception is NumberFormatException: For input string: "". I’d guess you internally convert int to string, without dealing explicitly with the NULL value. Sounds like an easy fix though.

Second row should not be all NULL

congress_session|bill_id                                    |random_stuff_1|bill_chamber|bill_resolution_type|bill_number|
----------------|-------------------------------------------|--------------|------------|--------------------|-----------|
             112|h,,1                                       |random payload|h           |                    |          1|
             112|NumberFormatException: For input string: ""|random payload|h           |r                   |           |

[serge-rider]

Yes, see milestone tag (on the top)