Gregory Wood wrote:
> Sorry, I was trying to give what I thought was a somewhat more concrete
> example without having to stipulate a number of qualifications. Let me
> rephrase to be more internationally correct: "If you are storing United
> States of America state abbreviations, they will ALWAY
Harrelson, CulleyX writes:
> Is there any difference between varchar and text other than varchar places a
> cap on the number of characters?
Varchar is SQL compliant, Text is not. You can use Varchar without a
character limit, but that is not SQL compliant either.
--
Peter Eisentraut [EM
Best, depending on the scenario. In cases where you are using a fixed number
of characters, there's no need for the overhead of a varchar. For instance
if you are storing state abbreviations, they will ALWAYS be 2 characters.
The database can look up those fixed fields
> Umm, sorry.
Sorry again, bad day mixed with feeling rubbed the wrong way.
> and (as pointed out on this thread) it's not even valid
> for the whole of the US.
That's new on me... I have a list of U.S. Postal Codes that all consist of
two letters. This includes all the U.S. states, territories
Martijn van Oosterhout wrote:
>
> I must have come over somewhat stronger than I intended.
> It was supposed to be just a passing comment. The reason
> I picked up on it is because it's the first thing people
> think of when looking for a reason for fixed length fields
> and (as pointed out on th
Gregory Wood wrote:
>
> > Does anyone else get annoyed when going on to an american site to
> > register or buy something and find that the state field is only
> > 2 characters long?
>
> Sorry, I didn't realize that many other countries had states... the only
> other frame of reference that I ha
Best, depending on the scenario. In cases where you
are using a fixed number
of characters, there's no need for the overhead of a
varchar. For instance
if you are storing state abbreviations, they will
ALWAYS be 2 characters.
The database can look up those fixed fields
