This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C85152.18536BAC
Content-Type: text/plain
Sounds good to me. This has been a bug-bear for me for a long time too.
-----Original Message-----
From: pgadmin-sup****t-owner@[EMAIL PROTECTED]
On Behalf Of Dave Page
Sent: Monday, January 07, 2008 10:11 AM
To: Kieran McCusker
Cc: pgadmin-sup****t@[EMAIL PROTECTED]
pgadmin-hackers@[EMAIL PROTECTED]
Re: [pgadmin-sup****t] Text column with large amounts of data
On 04/01/2008, Dave Page <dpage@[EMAIL PROTECTED]
> wrote:
> On 04/01/2008, Kieran McCusker <kieran.mccusker@[EMAIL PROTECTED]
> wrote:
> > Dave
> >
> > Does Max characters per column work in 1.8.1? Whatever I set the
limit
does
> > not seem to affect text fields?
>
> It should do, but maybe it got broken :-(. I'll add it to my todo list.
Yes, it did get broken quite a while back. The attached patch will fix
it again, but this is potentially problematic because
a) it's a non-obvious change in behaviour over last last few releases
b) the default setting means it will be turned on (because the default
value is 256, not zero).
c) we don't know if any data is actually truncated until the cell is
rendered, meaning we cannot popup a warning at query completion time.
The safest option seems to me to be to apply the patch to trunk, and
change the default to zero, using a different config option to ensure
we don't pickup the old default form prior installations.
Thoughts anyone?
/D
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
NOTICE: This electronic mail transmission may contain confidential
information and is intended only for the person(s) named. Any use,
copying
or disclosure by any other person is strictly prohibited. If you have
received this transmission in error, please notify the sender via e-mail.
------_=_NextPart_001_01C85152.18536BAC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: [pgadmin-sup****t] Text column with large amounts of =
data</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Sounds good to me. This has been a bug-bear for =
me for a long time too.</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: pgadmin-sup****t-owner@[EMAIL PROTECTED]
[<A =
HREF=3D"mailto:pgadmin-sup****t-owner@[EMAIL PROTECTED]
">mailto:pgadmin-supp=
ort-owner@[EMAIL PROTECTED]
>] On Behalf Of Dave Page</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, January 07, 2008 10:11 AM</FONT>
<BR><FONT SIZE=3D2>To: Kieran McCusker</FONT>
<BR><FONT SIZE=3D2>Cc: pgadmin-sup****t@[EMAIL PROTECTED]
=
pgadmin-hackers@[EMAIL PROTECTED]
>
<BR><FONT SIZE=3D2>Subject: Re: [pgadmin-sup****t] Text column with =
large amounts of data</FONT>
</P>
<P><FONT SIZE=3D2>On 04/01/2008, Dave Page <dpage@[EMAIL PROTECTED]
=
wrote:</FONT>
<BR><FONT SIZE=3D2>> On 04/01/2008, Kieran McCusker =
<kieran.mccusker@[EMAIL PROTECTED]
wrote:</FONT>
<BR><FONT SIZE=3D2>> > Dave</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > Does Max characters per column work in =
1.8.1? Whatever I set the limit does</FONT>
<BR><FONT SIZE=3D2>> > not seem to affect text fields?</FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>> It should do, but maybe it got broken :-(. I'll =
add it to my todo list.</FONT>
</P>
<P><FONT SIZE=3D2>Yes, it did get broken quite a while back. The =
attached patch will fix</FONT>
<BR><FONT SIZE=3D2>it again, but this is potentially problematic =
because</FONT>
</P>
<P><FONT SIZE=3D2>a) it's a non-obvious change in behaviour over last =
last few releases</FONT>
</P>
<P><FONT SIZE=3D2>b) the default setting means it will be turned on =
(because the default</FONT>
<BR><FONT SIZE=3D2>value is 256, not zero).</FONT>
</P>
<P><FONT SIZE=3D2>c) we don't know if any data is actually truncated =
until the cell is</FONT>
<BR><FONT SIZE=3D2>rendered, meaning we cannot popup a warning at query =
completion time.</FONT>
</P>
<P><FONT SIZE=3D2>The safest option seems to me to be to apply the =
patch to trunk, and</FONT>
<BR><FONT SIZE=3D2>change the default to zero, using a different config =
option to ensure</FONT>
<BR><FONT SIZE=3D2>we don't pickup the old default form prior =
installations.</FONT>
</P>
<P><FONT SIZE=3D2>Thoughts anyone?</FONT>
</P>
<P><FONT SIZE=3D2>/D</FONT>
</P>
<BR>
<P><FONT =
SIZE=3D2>_______________________________________________________________=
_______</FONT>
<BR><FONT SIZE=3D2>This email has been scanned by the MessageLabs Email =
Security System.</FONT>
<BR><FONT SIZE=3D2>For more information please visit <A =
HREF=3D"http://www.messagelabs.com/email"
=
TARGET=3D"_blank">http://www.messagelabs.com/email</A>
</FONT>
<BR><FONT =
SIZE=3D2>_______________________________________________________________=
_______</FONT>
</P>
<BR>
<BR>
<P><B><FONT SIZE=3D2>NOTICE: This electronic mail transmission may =
contain confidential information and is intended only for the person(s) =
named. Any use, copying or disclosure by any other person is =
strictly prohibited. If you have received this transmission in error, =
please notify the sender via e-mail.</FONT></B></P>
<BR>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C85152.18536BAC--
|
