From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
Subject: | Re: PQescapeBytea is not multibyte aware |
Date: | 2002-04-05 23:25:03 |
Message-ID: | 10929.1018049103@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Joe Conway <mail(at)joeconway(dot)com> writes:
> But still, doesn't that mean roughly twice as much memory usage for each
> copy of the string? And I seem to remember Jan saying that each datum
> winds up having 4 copies in memory. It ends up impacting the practical
> length limit for a bytea value.
Well, once the data actually reaches Datum form it'll be in internal
representation, hence compact. I'm not sure how many copies the parser
will make in the process of casting to UNKNOWN and then to bytea, but
I'm not terribly concerned by the above argument.
> Wow. I didn't realize this was possible:
> test=# select X'ffff';
> ?column?
> ----------
> 65535
> (1 row)
> This does clearly conflict with the spec, but what about backward
> compatibility? Do you think many people use this capability?
No idea. I don't think it's documented anywhere, though...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2002-04-05 23:26:13 | Re: 16 parameter limit |
Previous Message | Jeff Davis | 2002-04-05 23:22:50 | Re: Suggestion for optimization |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2002-04-05 23:26:13 | Re: 16 parameter limit |
Previous Message | Tom Lane | 2002-04-05 23:18:19 | Re: 16 parameter limit |