String conversion to enum fails about pljava HOT 3 CLOSED

I guess this was fixed by your pull-request? (it didn't mention this issue).

from pljava.

Looks like the original reporter hasn't been back.

Report didn't include a reproducer, but I think I have one. REPRODUCER:

-- first define a simple function on something in the JRE that'll take and return a given string
CREATE FUNCTION asvarchar(inp varchar) RETURNS varchar
IMMUTABLE LANGUAGE java AS 'java.net.IDN.toUnicode(java.lang.String)';
-- and confirm it works
SELECT asvarchar('happy');
 asvarchar  
-----------
 happy

-- Now try with an enum
CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy');
CREATE FUNCTION asmood(inp varchar) RETURNS mood
IMMUTABLE LANGUAGE java AS 'java.net.IDN.toUnicode(java.lang.String)';
SELECT asmood('happy');
ERROR:  cache lookup failed for type 0

The original reporter did submit a pull request #5 but it went to the wrong place (it was merged two days after #3 moved the file being patched from src/ to pljava-so/, so the patched file is sitting there in the original location not being used).

If I make the same change in the current String.c, it compiles and doesn't seem to break stuff, but also doesn't change the error from my reproducer. So I don't think it's a fix yet.

Not sure I can go further without understanding how you (Thomas?) would actually want enum return types to be handled. Are SQL enum types simply newer than the code, and need to be added to a mapping somewhere? Was the original reporter's change (using Type_extension.typeId instead of elementType, deeper magic than I understand yet) on the right track?

I read in type/Type.h:

 * The Type class is responsible for data type conversions between the
 * Postgres Datum and the Java jvalue. A Type can also perform optimized
 * JNI calls that are type dependent (returning primitives) such as
 * CallIntMethod(...) or CallBooleanMethod(...). Consequently, the Type
 * of the return value of a function is responsible for its invocation.

so maybe there isn't an Enum class yet and there should be? On the other hand, it also says

 * Types that are not mapped will default to a java.lang.String mapping
 * and use the Form_pg_type text conversion routines.

and I would certainly expect text conversion to an SQL enum to work....

from pljava.

The PG enum_in routine expects the enum type's Oid as a second argument (where an array's element type would go). So the OP's original patch should indeed make returning a String enum value succeed. Indeed it does, as I try my reproducer above again ... not sure what I did wrong in July when I thought it didn't.

The only problem I can imagine it causing would be if a String typeclass is ever used for a PG type that already has something meaningful in elementType. What could that be? An array? Will PL/Java ever use a String typeclass for a PG array? My quick experiments suggest no....

It might be more conservative to check for typtype of e in String_create, and initialize elementType to typeId only in that case.

from pljava.