On Sat, Jul 08, 2006 at 05:54:26PM -0400, Jim Nasby wrote:
+1. If there's enough user demand we can look at adding the type to
core (I don't see any real advantage to contrib over pgFoundry for
this). I'm not sure if it makes sense to add a generic 16 byte RAW to
core, either. I'd *much*
On Jul 6, 2006, at 4:02 PM, Thomas Hallgren wrote:
In answer to your question, though my opinion carries no special
weight at
all, I would suggest adding a bare bones 16-byte data type to core
and a
second binary-compatible data type based on it that parsed/output
as uuids.
The extended
On Saturday 08 July 2006 14:54, Jim Nasby wrote:
On Jul 6, 2006, at 4:02 PM, Thomas Hallgren wrote:
In answer to your question, though my opinion carries no special
weight at
all, I would suggest adding a bare bones 16-byte data type to core
and a
second binary-compatible data type
On Thu, Jun 29, 2006 at 06:47:17PM +0200, Martijn van Oosterhout wrote:
It seems to me that maybe the backend should include a 16-byte fixed
length object (after all, we've got 1, 2, 4 and 8 bytes already) and
then people can use that to build whatever they like, using domains,
for example...
On Thu, Jul 06, 2006 at 12:12:18PM -0400, [EMAIL PROTECTED] wrote:
Please answer the below questions, and state whether your opinion is
just an opinion, or whether you are stating it as a PostgreSQL
maintainer and it is law. If you wish, you can rank preferences.
Do I have to pick only one?
On 7/6/06, [EMAIL PROTECTED] wrote:
Please answer the below questions, and state whether your opinion is
just an opinion, or whether you are stating it as a PostgreSQL
maintainer and it is law. If you wish, you can rank preferences.
1) The added 128-bit type should take the form of:
a)
[EMAIL PROTECTED] writes:
e) Generic n-byte binary data type generator. Not sure of feasibility
of this at this point. See thread.
I don't like the idea of a generator that would have to be manually invoked,
though such a thing would be a fine tool for contrib or pgfoundry, I think
Hi,
Just MHO:
1) The added 128-bit type should take the form of:
c) UUID, with only encode/decode/indexable - generic except for the
name of the type, and the encoding format.
2) According to your answer in 1), the added 128-bit type should be:
a) In core first.
1c is what I
Greg Stark wrote:
In answer to your question, though my opinion carries no special weight at
all, I would suggest adding a bare bones 16-byte data type to core and a
second binary-compatible data type based on it that parsed/output as uuids.
The extended uuid libraries should only go in
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Hm, so it could be stored on disk without the length header as long as
the length header is added to the in-memory representation? I don't
think the type system has hooks for reading and storing data to disk
though.
On Thu, Jun 29, 2006 at 02:40:15AM -0400, Greg Stark wrote:
Greg Stark [EMAIL PROTECTED] writes:
No, it doesn't, and we'd pay a nonzero price for allowing that.
Currently the executor doesn't have to care (much) about whether a
tuple is on-disk or in-memory --- the individual datums look
Martijn van Oosterhout kleptog@svana.org writes:
A tuple is just an array of datums, with some header information. The
problems come when you don't have a tuple anymore, but only the datum,
like in arguments for functions.
I think it's more a case that most places that deal with datums
Greg Stark wrote:
Martijn van Oosterhout kleptog@svana.org writes:
To be honest, it seems like a lot of work to save the four bytes of
overhead for the varlena structure on disk if you're going to need it
in memory anyway. And anything like RAW(16) which people want for
UUIDs, if it's going
On Thu, Jun 29, 2006 at 03:54:36PM +0200, Thomas Hallgren wrote:
I have to concur with this. Assume you use a bytea for a UUID that in
turn is used as a primary key. The extra overhead will be reflected in
all indexes, all foreign keys, etc. In a normalized database some tables
may consist
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Jun 29, 2006 at 03:54:36PM +0200, Thomas Hallgren wrote:
I have to concur with this. Assume you use a bytea for a UUID that in
turn is used as a primary key. The extra overhead will be reflected in
all indexes, all foreign keys,
Greg Stark [EMAIL PROTECTED] writes:
In the current setup the only reason for Postgres to have this data type at
all is purely for legacy compatibility.
Yes. So?
regards, tom lane
---(end of broadcast)---
TIP 1: if
Martijn van Oosterhout wrote:
On Thu, Jun 29, 2006 at 03:54:36PM +0200, Thomas Hallgren wrote:
I have to concur with this. Assume you use a bytea for a UUID that in
turn is used as a primary key. The extra overhead will be reflected in
all indexes, all foreign keys, etc. In a normalized
On Thu, Jun 29, 2006 at 06:40:13PM +0200, Thomas Hallgren wrote:
Martijn van Oosterhout wrote:
On Thu, Jun 29, 2006 at 03:54:36PM +0200, Thomas Hallgren wrote:
I have to concur with this. Assume you use a bytea for a UUID that in
turn is used as a primary key. The extra overhead will be
Tom Lane [EMAIL PROTECTED] writes:
Martijn van Oosterhout kleptog@svana.org writes:
The input functions get it, the output functions (bpcharout,
bpcharsend, etc) don't. Which makes it kind of hard to print a raw
value if you don't know how long it's going to be. They used to, but
that
Greg Stark [EMAIL PROTECTED] writes:
Hm, so it could be stored on disk without the length header as long as
the length header is added to the in-memory representation? I don't
think the type system has hooks for reading and storing data to disk
though.
No, it doesn't, and we'd pay a nonzero
20 matches
Mail list logo
