Tom Lane wrote:
> Now that you mention it, though, doesn't TOAST break heapam's assumption
> that char(n) is fixed length? Seems like we'd better either remove that
> assumption or mark char(n) nontoastable. Any opinions which is better?
Is the saved overhead from assuming char(n) is fixe
Tom Lane wrote:
> Now that you mention it, though, doesn't TOAST break heapam's assumption
> that char(n) is fixed length? Seems like we'd better either remove that
> assumption or mark char(n) nontoastable. Any opinions which is better?
Is the saved overhead from assuming char(n) is fixe
I've wondered that myself, actually. What are the benefits and
drawbacks to going with one over the other, besides the obvious 255-char
field length limit for varchar? The reason to stay away from "memo"
fields in other serious RDBMSs are typically more difficult maintenance,
significantly lower
On Tue, 22 Aug 2000, Tom Lane wrote:
> Tressens Lionel <[EMAIL PROTECTED]> writes:
> > Le 22.08.00 a 09:37, "Roderick A. Anderson" m'ecrivait :
> > )I was able to get the table format by using MS Access. Only question left
> > )is what is the corresponding field type in PostgreSQL for a memo fie
Tressens Lionel <[EMAIL PROTECTED]> writes:
> Le 22.08.00 a 09:37, "Roderick A. Anderson" m'ecrivait :
> )I was able to get the table format by using MS Access. Only question left
> )is what is the corresponding field type in PostgreSQL for a memo field in
> )SQL Server/Access (varchar())?
>
Le 22.08.00 a 09:37, "Roderick A. Anderson" m'ecrivait :
)I was able to get the table format by using MS Access. Only question left
)is what is the corresponding field type in PostgreSQL for a memo field in
)SQL Server/Access (varchar())?
'text' type perhaps ?
Lionel
