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
A thanks to everyone on this list and especially; Jeffery Rhines, Chris
Knight, Chris Bitmead, and Sevo Stille.
The solution turned out to be very simple. After catching a SCSI BUS
speed mismatch problem which caused a NT Backup 'Restore' failure I
discovered that the actual data was in .mdb fil
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
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
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())?
>
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
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
