Martijn van Oosterhout wrote:
> On Wed, Jun 28, 2006 at 01:56:47PM +0200, Thomas Hallgren wrote:
>> A user that is trusted with installing a C-function in the backend is
>> free to scan the process memory anyway so in what way did that increase
>> the security? IMHO, the only relevant security in that context is to
>> have trusted people install trusted modules. I'm surprised that
>> something like that made you remove significant functionality.
>
> You're missing the point. The type output function is not generally a
> priveledged function. Think bpcharout, text_out, numeric_out, etc...
> These can be called by users directly and the input to those functions
> cannot be trusted.
>
Ah, OK that makes sense. An alternative solution when the signature was changed could
perhaps have been to pass one single argument, a structure appointing the data and its
associated type. My idea would work if the data and its type lived together always from the
moment its instantiated (read from disk or otherwise) and until death do them apart (or the
data is stored on disk, in which case the tupledesc knows what it is). I guess that would
imply a major rewrite and that my desire to have a RAW fixed length type isn't enough
motivation to do that :-)

Instead, I would like to humbly request the inclusion of a UUID datatype (or an opaque 128
bit datatype) in the core package. It's increasingly common and some databases (MS
SQLServer) already have built in support for it.

Regards,
Thomas Hallgren


---------------------------(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 Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
> Instead, I would like to humbly request the inclusion of a UUID datatype
> (or an opaque 128 bit datatype) in the core package. It's increasingly

ISTM that we get enough requests for this that it's probably worth
doing.
--
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 5: don't forget to increase your free space map settings

On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
> Instead, I would like to humbly request the inclusion of a UUID datatype
> (or an opaque 128 bit datatype) in the core package. It's increasingly
> common and some databases (MS SQLServer) already have built in support for
> it.

We have it. We're just not putting in the effort required to have it
included in core, as it's too much effort to convince people that the
type has value, that is is generic, and would be widely used without
being abused. All the geometric types that I'll never use in core,
with few or no uses, including functions to operate on these types,
and no UUID type... Hehe... To me, that's irony... :-)

Cheers,
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 2: Don't 'kill -9' the postmaster

On Wed, June 28, 2006 1:14 pm, mark@mark.mielke.cc wrote:
> On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
>
>> Instead, I would like to humbly request the inclusion of a UUID
>> datatype (or an opaque 128 bit datatype) in the core package. It's
>> increasingly common and some databases (MS SQLServer) already have built
>> in support for it.
>
> We have it. We're just not putting in the effort required to have it
> included in core, as it's too much effort to convince people that the type
> has value, that is is generic, and would be widely used without being
> abused. All the geometric types that I'll never use in core, with few or
> no uses, including functions to operate on these types, and no UUID
> type... Hehe... To me, that's irony... :-)

Is it on pgfoundry? From past discussions, the new criteria for getting
something into core is to first determine if it is successful on
pgfoundry.


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Wed, Jun 28, 2006 at 01:18:39PM -0400, A.M. wrote:
> On Wed, June 28, 2006 1:14 pm, mark@mark.mielke.cc wrote:
> > On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
> >
> >> Instead, I would like to humbly request the inclusion of a UUID
> >> datatype (or an opaque 128 bit datatype) in the core package. It's
> >> increasingly common and some databases (MS SQLServer) already have built
> >> in support for it.
> >
> > We have it. We're just not putting in the effort required to have it
> > included in core, as it's too much effort to convince people that the type
> > has value, that is is generic, and would be widely used without being
> > abused. All the geometric types that I'll never use in core, with few or
> > no uses, including functions to operate on these types, and no UUID
> > type... Hehe... To me, that's irony... :-)
>
> Is it on pgfoundry? From past discussions, the new criteria for getting
> something into core is to first determine if it is successful on
> pgfoundry.

If http://lnk.nu/pgfoundry.org/a86.php is accurate, then no one has ever
downloaded it. But I find that exceptionally hard to believe...

Looking back through the list archives I think you'd find this comes up
at least every few months.
--
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 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 Wed, Jun 28, 2006 at 12:38:50PM -0500, Jim C. Nasby wrote:
> On Wed, Jun 28, 2006 at 01:18:39PM -0400, A.M. wrote:
> > On Wed, June 28, 2006 1:14 pm, mark@mark.mielke.cc wrote:
> > > On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
> > >> Instead, I would like to humbly request the inclusion of a UUID
> > >> datatype (or an opaque 128 bit datatype) in the core package. It's
> > >> increasingly common and some databases (MS SQLServer) already have built
> > >> in support for it.
> > > We have it. We're just not putting in the effort required to have it
> > > included in core, as it's too much effort to convince people that the type
> > > has value, that is is generic, and would be widely used without being
> > > abused. All the geometric types that I'll never use in core, with few or
> > > no uses, including functions to operate on these types, and no UUID
> > > type... Hehe... To me, that's irony... :-)
> > Is it on pgfoundry? From past discussions, the new criteria for getting
> > something into core is to first determine if it is successful on
> > pgfoundry.
> If http://lnk.nu/pgfoundry.org/a86.php is accurate, then no one has ever
> downloaded it. But I find that exceptionally hard to believe...
>
> Looking back through the list archives I think you'd find this comes up
> at least every few months.

I've downloaded the version off pgfoundry.org. It is broken. It leaks
memory, and if memory is correct it can cause the client to core dump.

Two of us worked on a re-write based off a different UUID system library,
and I've been happily using it in production for a year or so. I don't
believe either of us have bothered to market it. Each time it comes up,
a number of people on this list shut it down, and it doesn't seem worth
the effort to convince them otherwise. They can have their ivory tower,
and I can have my plugin.

Cheers,
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 3: Have you checked our extensive FAQ?

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

Jim C. Nasby wrote:

>On Wed, Jun 28, 2006 at 01:18:39PM -0400, A.M. wrote:
>
>
>>On Wed, June 28, 2006 1:14 pm, mark@mark.mielke.cc wrote:
>>
>>
>>>On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
>>>
>>>
>>>
>>>>Instead, I would like to humbly request the inclusion of a UUID
>>>>datatype (or an opaque 128 bit datatype) in the core package. It's
>>>>increasingly common and some databases (MS SQLServer) already have built
>>>>in support for it.
>>>>
>>>>
>>>We have it. We're just not putting in the effort required to have it
>>>included in core, as it's too much effort to convince people that the type
>>>has value, that is is generic, and would be widely used without being
>>>abused. All the geometric types that I'll never use in core, with few or
>>>no uses, including functions to operate on these types, and no UUID
>>>type... Hehe... To me, that's irony... :-)
>>>
>>>
>>Is it on pgfoundry? From past discussions, the new criteria for getting
>>something into core is to first determine if it is successful on
>>pgfoundry.
>>
>>
>
>If http://lnk.nu/pgfoundry.org/a86.php is accurate, then no one has ever
>downloaded it. But I find that exceptionally hard to believe...
>
>Looking back through the list archives I think you'd find this comes up
>at least every few months.
>
>

That's because there is nothing there to download. See instead:
http://gborg.postgresql.org/project/...rojdisplay.php

Personally I don't buy the misuse objection - we already have plenty of
things that can be misused. As long as there is a reasonable valid use
and we can make it portable enough, I think there is a good case for
including it.

cheers

andrew

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

mark@mark.mielke.cc wrote:

> I've downloaded the version off pgfoundry.org. It is broken. It leaks
> memory, and if memory is correct it can cause the client to core dump.

Also it couldn't possibly be included in core, since it's based on a
GPL'ed UUID library. If you have a more appropiately licensed package,
it could be considered for inclusion.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(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 Wed, Jun 28, 2006 at 01:49:55PM -0400, Andrew Dunstan wrote:
> Personally I don't buy the misuse objection - we already have plenty of
> things that can be misused. As long as there is a reasonable valid use
> and we can make it portable enough, I think there is a good case for
> including it.

Well, since Mark has one, how about we consider adding it in?

If nothing else, can you please put your stuff on pgFoundry so others
can find it, Mark?
--
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 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 Wed, Jun 28, 2006 at 01:12:17PM -0500, Jim C. Nasby wrote:
> On Wed, Jun 28, 2006 at 01:49:55PM -0400, Andrew Dunstan wrote:
> > Personally I don't buy the misuse objection - we already have plenty of
> > things that can be misused. As long as there is a reasonable valid use
> > and we can make it portable enough, I think there is a good case for
> > including it.
> Well, since Mark has one, how about we consider adding it in?
> If nothing else, can you please put your stuff on pgFoundry so others
> can find it, Mark?

It was written by Nathan Wagner <nw@hydaspes.if.org> and myself, and
is based off the OSSP ( http://www.ossp.org/ ) UUID implementation.
I'm not an expert on the license, but it seems acceptable to me:

"Permission to use, copy, modify, and distribute this software for
any purpose with or without fee is hereby granted, provided that
the above copyright notice and this permission notice appear in all
copies."

I haven't tested to see how portable the OSSP UUID implementation is.
This is their words:

"OSSP uuid was already written with maximum portability in mind, so
there should be no great effort required to get it running on any Unix
platform with a reasonable POSIX API. Additionally, the portability
was tested by successfully building and running it on the following
particular Unix platforms (syntax is "<cpu>-<os> (<compiler>)"):

alpha-tru644.0 (cc)
alpha-tru645.1 (gcc, cc)
hppa-hpux11.11 (cc)
ia64-hpux11.23 (cc)
ix86-debian2.2 (gcc, icc)
ix86-debian3.0 (gcc)
ix86-debian3.1 (gcc)
ix86-freebsd4.9 (gcc)
ix86-freebsd5.2 (gcc, icc)
ix86-netbsd1.6 (gcc)
ix86-qnx6.2 (gcc)
ix86-solaris10 (gcc)
ix86-unixware7.1.3 (cc)
mips64-irix6.5 (gcc)
sparc64-solaris8 (gcc, forte)
sparc64-solaris9 (gcc)"

I've put it through a fair amount of testing, including using it
within compound indexes, expecting the index to be used for at
least '=', constructing many UUIDs quickly, in a sequence, and
converting it to and from string form. We chose to implement our
own encode / decode routines for performance reasons. With the
exception of testing it on a wider range of platforms, I would
call the module stable.

If there is interest - I'm sure Nathan and I would be willing to put
it on pgfoundry, and at some point give it up for inclusion into
PostgreSQL.

Cheers,
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 3: Have you checked our extensive FAQ?

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