On Fri, Jun 30, 2006 at 12:45:13PM -0500, Jim C. Nasby wrote:
If people agree to a generic 16-byte type, or a hex type with defined
fixed length with a set of standard functions and index operators that
it should work for, but nobody more qualified wants to make the patch
- I'll step up.
Martijn van Oosterhout kleptog@svana.org writes:
It would also be possible to provide two functions called hex_raw_in()
and hex_raw_out() that people could use like so:
CREATE TYPE uuid (
input = hex_raw_in,
output = hex_raw_out,
INTERNALLENGTH = 16
);
Where these input/output
On Sat, Jul 01, 2006 at 10:37:59AM -0400, Tom Lane wrote:
Where these input/output functions would work for any given length, so
the 16 could be replaced by any number, or even -1 to make a variable
length type...
I believe you could make an input function that would support that,
though
Tom Lane wrote:
The output function, however, would be quite a trick.
It's not going to receive anything except the Datum itself.
I understand the reasons for this limitation of output functions, but I
have now seen it bite several times. Maybe we need a little out of the
box
On Sat, Jul 01, 2006 at 10:58:05AM -0400, Andrew Dunstan wrote:
Tom Lane wrote:
The output function, however, would be quite a trick.
It's not going to receive anything except the Datum itself.
I understand the reasons for this limitation of output functions, but I
have now seen it bite
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Jul 01, 2006 at 10:37:59AM -0400, Tom Lane wrote:
The output function, however, would be quite a trick.
It's not going to receive anything except the Datum itself.
Hmm, you're right. With the taggedtypes module I made it work by
Martijn van Oosterhout kleptog@svana.org writes:
Something that has been discussed in the past is allowing non-strict
type input/output functions to be evaluated at query execution time,
rather than during parse time. This would give the type input/output
functions the Expr node they need to
Jim,
I agree about splitting the utilities, except that I think the database
should be able to generate UUIDs somehow.
There is a GUID add-in, and someone is working on a 2nd one. UUIDs are
not part of the SQL standard, and we've only seen sporadic demand for
them (and different types each
Josh Berkus wrote:
Jim,
I agree about splitting the utilities, except that I think the database
should be able to generate UUIDs somehow.
There is a GUID add-in, and someone is working on a 2nd one. UUIDs
are not part of the SQL standard, and we've only seen sporadic demand
for them (and
On Fri, Jun 30, 2006 at 08:53:28AM +0200, Thomas Hallgren wrote:
Josh Berkus wrote:
I agree about splitting the utilities, except that I think the database
should be able to generate UUIDs somehow.
There is a GUID add-in, and someone is working on a 2nd one. UUIDs
are not part of the
On Fri, Jun 30, 2006 at 04:04:19AM -0400, [EMAIL PROTECTED] wrote:
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
On Fri, Jun 30, 2006 at 10:38:49AM +0200, Martijn van Oosterhout wrote:
On Fri, Jun 30, 2006 at 04:04:19AM -0400, [EMAIL PROTECTED] 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
On Fri, Jun 30, 2006 at 12:39:52PM -0400, [EMAIL PROTECTED] wrote:
Only this could be used to create other types too, for cryptographic
functions for example. PostgreSQL doesn't have any type generators yet,
so I'm unsure whether a patch creating one would be accepted for core.
Not sure
[EMAIL PROTECTED] writes:
It depends how it is used. If the memory location needs to be
allocated, for the value to be used only a few times, the overhead of
allocation and redirection can be more expensive. If many though, than
the reduction in value copying can make the pointer faster.
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
On Thu, Jun 29, 2006 at 02:02:32AM -0400, [EMAIL PROTECTED] wrote:
It was written by Nathan Wagner [EMAIL PROTECTED] 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:
...
If there is interest -
[EMAIL PROTECTED] wrote:
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
[EMAIL PROTECTED] wrote:
On Thu, Jun 29, 2006 at 02:02:32AM -0400, [EMAIL PROTECTED] wrote:
It was written by Nathan Wagner [EMAIL PROTECTED] 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:
...
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.
One requirement would be that it runs on Windows. Is that something you
have tested?
In case it influences anyone, MySQL 5 already has built-in
On Thu, Jun 29, 2006 at 09:12:32AM +0200, Thomas Hallgren wrote:
The split make sense since clients often have powerful UUID utilities handy
and hence have limited or no use for such utilities in the database (true
for all .NET and Java clients). Some PL's will also enable such packages
out
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
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.
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
On Wed, June 28, 2006 1:14 pm, [EMAIL PROTECTED] 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
On Wed, Jun 28, 2006 at 01:18:39PM -0400, A.M. wrote:
On Wed, June 28, 2006 1:14 pm, [EMAIL PROTECTED] 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
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, [EMAIL PROTECTED] wrote:
On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
Instead, I would like to humbly request the
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, [EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
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.
29 matches
Mail list logo
