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 reflected in
> >>all indexes, all foreign keys, etc. In a normalized database some tables
> >>may consist of UUID columns only.
> >>
> >
> >So you create a UUID type. It's cheap enough to create new types after
> >all, that's one of postgresql's strengths.
> It would be a whole lot easier if I could use a domain.

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...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEpAQVIB7bNG8LQkwRAouyAJ9okPZSYoUPiQm5vKesOy BX5tjwKACfYeDT
mIlGa8MsfT7a/Eahp/nx6wM=
=7gky
-----END PGP SIGNATURE-----

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...

Sooooo... Back to this.

It won't happen unless somebody does it - and I realize that people
are busy with their own projects, so unless somebody more willing and
better suited will step up, I'm going to take a stab at getting
advanced consensus.

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) UUID, with all functions
b) UUID, with only basic generation functions + encode/decode/indexable
c) UUID, with only encode/decode/indexable - generic except for the
name of the type, and the encoding format.
d) Generic 128-bit type - same as c) except may not encode or decode
as UUID (dashes). Either a large number (hex string?), or binary data.
e) Generic n-byte binary data type generator. Not sure of feasibility
of this at this point. See thread.

2) According to your answer in 1), the added 128-bit type should be:

a) In core first.
b) In contrib first.
c) In pgfoundry first.


Thanks,
mark

--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
.. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Thu, Jul 06, 2006 at 12:12:18PM -0400, mark@mark.mielke.cc 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? I'd choose firstly for:

1c) UUID, with only encode/decode/indexable - generic except for the
name of the type, and the encoding format.
2a) In core first

And in addation to that:

1b) UUID, with only basic generation functions +
encode/decode/indexable
2b) In contrib first.

And maybe finally:

1a) UUID, with all functions
2c) In pgfoundry first.

IOW, I'm not so convinced that full UUID support should appear in core,
but I think a 16-byte type should be available in core, with basic UUID
functions in contrib and the full suite on pgfoundry.

But that's just my opinion ofcourse.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFErTxuIB7bNG8LQkwRAgS2AJ436bX77nXQENO/qIE69A9/SkgNEACcCku4
1pdbCN6qkFPoIXJOs/RRhvM=
=8ZQM
-----END PGP SIGNATURE-----

On 7/6/06, mark@mark.mielke.cc 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) UUID, with all functions

> 2) According to your answer in 1), the added 128-bit type should be:
>
> a) In core first.

Opinion, 1 a, 2 a

Jochem

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

mark@mark.mielke.cc 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 it
would never be a clean enough interface for core.

On the other hand core could conceivably translate things like char(n) into
such a type generated on the fly. That is, instead of having a single char oid
it could check a cache of fixed length char(n) data types and if there isn't
one already generate one on the fly. That would be somewhat grotty of an
implementation but the user interface at least would be entirely transparent.
If one day we change things to pass around typmod database designs wouldn't
have to change at all.

(Actually Postgres can never do this for char(n), at least not as long as we
insist on making char/varchar/text locale-aware. Personally I think the
default char/varchar/text locale should be C unless you specify otherwise on a
per-column basis. But that seems to be a minority opinion. Postgres could
however do this for separate raw binary datatypes like bit(n) or bytea(n).)

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 pgfoundry/contrib.

--
greg


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 would need. 1b or 1a would be nice to have.

- Sander



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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 pgfoundry/contrib.
>
I second that.

Regards,
Thomas Hallgren


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 uuid libraries should only go in pgfoundry/contrib.
> I second that.

+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* rather see effort expended on a generic RAW
type which had it's size defined as part of the type and didn't use
varlena.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 based on it that parsed/output
> >> as uuids.
> >> The extended uuid libraries should only go in pgfoundry/contrib.
> >
> > I second that.
>
> +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).

The advantage of contrib over pgFoundry is that it will be packaged by the
major distributions. Every distribution includes a package of the contrib
modules.

Sincerely,

Joshua D. Drake


--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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* rather see effort expended on a generic RAW
> type which had it's size defined as part of the type and didn't use
> varlena.

You could place a nice wrapper around type generators, which would let
you say:

DECLARE TYPE RAW(16);

After which point you could use that type in function declarations and
such. It would create an OID for that type would could be used as
normal.

I think that trying to get the backend to pay more attention to typmods
is not going to be successful. Simply because functions and operators
have an affect on the typmod and once you start relying on typmods to
decode a tuple, you've got a real problem.

As an example, what do you get when you concatenate two CHAR(4)'s? Do
you get another CHAR(4) or is it a CHAR(8)? How does the backend know?
You'd have to accompany each function with another function just to
tell you how the typmods would be related.

The only way out I can think of is that RAW(n) is merely a sort of
template and RAW(x) cannot be used in a place where RAW(y) is expected
(if x<>y). Hence it makes sense to have a template that people can
instantiate instances of and let the rest of the system treat them as
new types, unrelated to anything else.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEsQXwIB7bNG8LQkwRAsNVAJ9zPQNxfvY7uS+vQgfnYr iu/ZLxigCffOQ7
8S6g8bZFCuUwZTlwjVTiqz0=
=LZlJ
-----END PGP SIGNATURE-----