Alexander Borkowski wrote:
>
>> Type handling really needs a major rewrite, but it's so boring...
> Can you roughly outline what would be involved in doing this?
There's already some stuff in pgDatatype, but the class was invented too
late when I realized that typehandling is more complicated than it
appeared initially. Every string/parameter formatting/encoding should be
concentrated there. This involves some rewrite of type usage in schema
and ui files as well.
>>> 5. Creating a composite type requires at least two member fields to be
>>> added (the OK button stays disabled until there are at least two
>>> members defined). According to line 240 of src/ui/dlgType.cpp this is
>>> intentional, but at least according to my PostgreSQL documentation it
>>> is valid to have a composite type with just one field. IMHO this does
>>> make sense, as one can create a table with only one column as well.
>>> Am I missing something?
>>
>>
>> This is subject to discussion. For most users, probably it's correct
>> to restrict composite types to have >1 member; less doesn't make too
>> much sense (I'd suggest a domain instead). Not everything that's legal is
>> also sensible, so I'd opt to leave this a little restricted to reduce
>> newbie's surprises.
>
>
> Is do see your point. May I nevertheless suggest a warning dialog
> instead? Something along the lines of: "You are trying to create a
> composite type with only one member.
We're planning a guru hint mechanism for 1.3/1.4, so this is certainly a
candidate.
Regards,
Andreas
