Thank you for your reply. I think the ordering by oid as a fallback is fine... I assume postgres generates the oids in the right order when storing the type, so the effective result will be the same as using pg_enum.enumsortorder, provided I don't try to reorder the enum type fiddling with the internals ( adding an additional enum value is possible in 9.1., I checked that, but that won't interfere with the order since the oid is strictly monotonic.... )
When updating the pg_enum.enumorder by hand I'd break even this workaround. Maybe one should mention in the documentation that this is a bad idea. keep up the good work :) Patrik -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
