"Daniel Migowski" <dmigowski@ikoffice.de> writes:
> What would be the problem with this? text fields ARE memo fields. Use
> varchar(n) if you want length constrained fields :).
Well if I understand correctly memo fields are much less functional than text
fields. In short the mapping between Postgres types and types of other
databases is imperfect and what type is the closest match will depend on which
properties are most important. IIUC memo fields cannot be used in queries the
way text fields can, passed to functions, and stored in variables etc. The
ability to not declare a length constraint is a fairly minor distinguishing
property that doesn't impact the application much.
>> Perhaps this is all just FUD though.
>
> In fact LONGVARCHAR is made easy in JDBC, since it is required to be accessible
> by the same functions as VARCHAR.
Sure, but that doesn't mean tools will make the right decision. It'll be
positively weird for a tool to provide a different set of options to the user
if it sees a text field rather than a varchar for example since in Postgres
they're almost exactly equivalent.
>> I haven't seen such a case myself. I was
>> under the impression such cases had been previously posted on list but if
>> you've searched and not found anything then perhaps I'm thinking of some other
>> scenario.
>
> In fact I searched for LONGVARCHAR on the list, and everything I got are
> complaints that it is not supported in the metadata (in about 4 threads). Of
> course we could not get complaints for the reversed case, in which LONGVARCHAR
> itself was a problem, yet.
Right, searching for LONGVARCHAR isn't going to find problems since it's not
the way Postgres worked in the past. Perhaps searching for "memo" or "lob" or
something like that might work. But I'm being unfair, I guess I have to do
this search myself if I still think there's a problem :)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
