[HACKERS] Fixed length datatypes. WAS [GENERAL] UUID's as primary keys

2006-06-28 Thread Thomas Hallgren

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 [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] Fixed length datatypes. WAS [GENERAL] UUID's as primary keys

2006-06-28 Thread Jim C. Nasby
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  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 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


Re: [HACKERS] Fixed length datatypes. WAS [GENERAL] UUID's as primary keys

2006-06-28 Thread mark
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

-- 
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] 
__
.  .  _  ._  . .   .__.  . ._. .__ .   . . .__  | 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