foreign key dropdown doesn't handle citext on postgres

[MolallaComm]

When editing int identity columns, in addition to the identity key, Heidi also usually displays the first varchar or text column in hopes of making things more human readable. I noticed that if the FK table is using "citext" instead of "text" columns it doesn't work (the identity numbers still show up in the dropdown but not the human readable part). If I change the column from "citext" to "text" and refresh, it works as expected.

Unfortunately, using case insensitive coalations even in this day and age with postgres is often problematic for many reasons so we and many others use citext to work around these limitations. Would be nice if Heidi worked for citext as well as varchar and text on postgres.

[ansgarbecker]

I was just trying to create a test table with a CITEXT column, but to my surprise, on Postgesql 15.1, I get an SQL error saying the type "CITEXT" does not exist:

CITEXT Documentation says it should work from PostgreSQL 12.0+ so it should work on my local server.

But the documentation also says something about a module installation, and I did not install any module. I have no clue what that means. Can you shed some light on that?

[MolallaComm]

Yes, citext is included with the default distribution but it isn't enabled by default - you have to do something like:

CREATE EXTENSION citext;

to enable it for each database you want to use it in.

[ansgarbecker]

Thanks for the tip. That did it.

CITEXT is now supported in the next builds, and categorized as text type, so it shows up in the foreign value pulldown you mentioned.

Note the value in IS.columns.data_type is "USER-DEFINED" for such extension based types. I worked around that by using the value in udt_name, which was the correct "citext" in my test case.

I'm crossing fingers the hardcoded oid 24651 is unique everywhere, and not only on my local server:

HeidiSQL/source/dbstructures.postgresql.pas

Line 239 in 4ac4152

NativeTypes: '24651';

[MolallaComm]

Yes - unfortunately - I think the oid changes from server to server/database to database. I was recently doing some similar work and noticed on my machine that citext was 2606673 but on the production server it was 59586 - i think the built in types are always the same, but ones from extensions like citext will vary. Hopefully that won't throw a wrench in things - if you want, i can download tomorrows build and verify for sure that it doesn't work, but I'm reasonably confident it won't if it is counting on 24651 being associated with citext.

[ansgarbecker]

Yes, that would be helpful if you give it a test and give some feedback. The new build should be available in roughly half an hour.

[ansgarbecker]

Similar issue in a different project: launchbadge/sqlx#295

[MolallaComm]

Yep - not sure if it helps, but the SQL to get it seems to be:

SELECT 'citext'::regtype::oid;

and I did confirm it is different on every server I tried. Also, this article discusses getting it via the C api:

https://stackoverflow.com/questions/45887484/get-user-defined-type-oid-in-postgresql-extension-c

[ansgarbecker]

I decided for the xyz::regtype::oid query you mentioned, which is now fired along with the very first query on the connection. This should work on all servers, even if the query fails for some reason - a potential crash is suppressed.

Minor drawback is that this query is fired once on each session, anyway if there is a citext type or not. This is due to a still hardcoded list of data types in HeidiSQL, with citext being one of them. Only dynamic thing is the oid of citext now.

Looking at the pg_type table, I just realized how many data types PosgreSQL has (~300 + ~300 array types), and how few of these are supported in HeidiSQL (~40). So an idea for the future would be to replace the hardcoded data types with a dynamically built list. I only suspect this won't be doable with MySQL and the other protocols.