On Apr 2, 2006, at 6:13 PM, Tom Lane wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
On 4/2/06, Tom Lane [EMAIL PROTECTED] wrote:
If you're expecting that you'll be able to write BYTEA(n) and avoid
storing a length word, you'll find that it's not a trivial matter.
It may not be trivial,
On Mon, Apr 03, 2006 at 01:31:50PM -0400, Jim Nasby wrote:
I'm not sure how other databases handle this, but I suspect it would
be OK performance-wise to tack on a length byte for these types when
dealing with functions and anything else that isn't directly tied to
a table where you can
On Sat, Apr 01, 2006 at 05:42:34PM +0200, Thomas Hallgren wrote:
Jim C. Nasby wrote:
On Fri, Mar 31, 2006 at 11:29:15AM -0500, Tom Lane wrote:
This argument falls flat when you consider that the width of a CHAR
entry is measured in characters, not bytes, and therefore its physical
size is not
Jim C. Nasby wrote:
On Sat, Apr 01, 2006 at 05:42:34PM +0200, Thomas Hallgren wrote:
Why not simply a fixed number of bytes, i.e. byte(16) or octet(16)?
Hexadecimal is just a convenient human-readable representation.
Well, hex is much easier to deal with in many regards than raw
Thomas Hallgren [EMAIL PROTECTED] writes:
Jim C. Nasby wrote:
Well, hex is much easier to deal with in many regards than raw bytes,
though. But yes, the idea is that you'd just store raw bytes on disk.
byte or octet would work fine if they existed.
IIRC, Oracle actually uses the term RAW.
On 4/2/06, Tom Lane [EMAIL PROTECTED] wrote:
bytea does that.
Yep. However, I've wanted to add a constrained, fixed-length version
of bytea for some time now; it's just not high on my priority list.
At EnterpriseDB, we've actually had a lot of customers who would
prefer a constrained bytea
Jonah H. Harris [EMAIL PROTECTED] writes:
Yep. However, I've wanted to add a constrained, fixed-length version
of bytea for some time now; it's just not high on my priority list.
If you're expecting that you'll be able to write BYTEA(n) and avoid
storing a length word, you'll find that it's
On 4/2/06, Tom Lane [EMAIL PROTECTED] wrote:
If you're expecting that you'll be able to write BYTEA(n) and avoid
storing a length word, you'll find that it's not a trivial matter.
It may not be trivial, but it's certainly not impossible.
--
Jonah H. Harris, Database Internals Architect
Jonah H. Harris [EMAIL PROTECTED] writes:
On 4/2/06, Tom Lane [EMAIL PROTECTED] wrote:
If you're expecting that you'll be able to write BYTEA(n) and avoid
storing a length word, you'll find that it's not a trivial matter.
It may not be trivial, but it's certainly not impossible.
A word to
On 4/2/06, Tom Lane [EMAIL PROTECTED] wrote:
Changing that is not impossible, but the level of pain vastly exceeds
what this feature would be worth.
I really like the wording, the level of pain... so true :)
you could create one or more fixed-size datatypes (ie, with various
positive typlen
On Fri, Mar 31, 2006 at 11:29:15AM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
About the only reason I use CHAR in other databases systems is when I
know that the field will always contain the same amount of data, ie:
storing a SHA1. In these cases it's silly to have a 4
Jim C. Nasby wrote:
On Fri, Mar 31, 2006 at 11:29:15AM -0500, Tom Lane wrote:
This argument falls flat when you consider that the width of a CHAR
entry is measured in characters, not bytes, and therefore its physical
size is not fixed even if its logical width is.
True, but in every case I've
Jonah H. Harris [EMAIL PROTECTED] wrote
Yeah, I noticed that one. How would you suggest setting
CLASS_TUPLE_SIZE in that case?
What if you put your char[64] before relhassubclass, then you don't change
CLASS_TUPLE_SIZE.
Regards,
Qingqing
---(end of
On 3/31/06, Qingqing Zhou [EMAIL PROTECTED] wrote:
What if you put your char[64] before relhassubclass, then you
don't change CLASS_TUPLE_SIZE.
Thought about that... but it would be an ugly place for this column.
I know I could get around it by renumbering the attribute, but that's
just a
On 3/31/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
What are you using a char[64] for anyway? You should probably consider
using NameData, if you want to store an identifier.
It's just a fixed length string that will never change in size and as
such, I'd like not to add the overhead of any
On Fri, Mar 31, 2006 at 10:45:15AM -0500, Jonah H. Harris wrote:
On 3/31/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
What are you using a char[64] for anyway? You should probably consider
using NameData, if you want to store an identifier.
It's just a fixed length string that will never
Jim C. Nasby [EMAIL PROTECTED] writes:
About the only reason I use CHAR in other databases systems is when I
know that the field will always contain the same amount of data, ie:
storing a SHA1. In these cases it's silly to have a 4 byte overhead to
store length. I really wish CHAR in
On 3/31/06, Tom Lane [EMAIL PROTECTED] wrote:
This argument falls flat when you consider that the width of a CHAR
entry is measured in characters, not bytes, and therefore its physical
size is not fixed even if its logical width is.
Gotta love multibyte :)
--
Jonah H. Harris, Database
I apologize for the lameness of this question upfront :)
Does anyone know how to add a fixed-length char field to pg_class? I
need to avoid the cost of variable-length so I tried to add the
fixed-length char[64] right before relacl and updated CLASS_TUPLE_SIZE
to reflect the fixed-size of the
Jonah H. Harris [EMAIL PROTECTED] writes:
Does anyone know how to add a fixed-length char field to pg_class?
Changing any of the bootstrap catalogs is fairly tricky --- there are a
lot of places you have to update manually. I'd suggest looking for a
previous commit that did something similar
On 3/30/06, Tom Lane [EMAIL PROTECTED] wrote:
Here are a couple of possibilities; the first
one is smaller but it's touching pg_proc not pg_class.
Yeah, I noticed that one. How would you suggest setting
CLASS_TUPLE_SIZE in that case?
--
Jonah H. Harris, Database Internals Architect
21 matches
Mail list logo
