Jim Nasby wrote:
Following that logic we should remove all data types that aren't
specified in ANSI.
Sure, if we were to arrive at some acceptable implementation of official
modules, that would make sense in some cases.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Sun, 2007-01-21 at 00:17 +0100, Gevik Babakhani wrote:
So.. do we agree for uuid to be included in the core?
I'd be curious to know the degree to which the proposed patch is
consistent with RFC 4122, which AFAIK is the most recent relevant
standard.
With regard to functions for generating
Neil Conway wrote:
On Sun, 2007-01-21 at 00:17 +0100, Gevik Babakhani wrote:
So.. do we agree for uuid to be included in the core?
I'd be curious to know the degree to which the proposed patch is
consistent with RFC 4122, which AFAIK is the most recent relevant
standard.
With regard to
Gevik Babakhani wrote:
So.. do we agree for uuid to be included in the core?
I suggest that you read the discussion in the tsearch thread about
figuring out how to make contrib modules more attractive. I don't see
a reason why uuid has to be in the core, but I do see that there needs
to be
On Thu, 2007-01-25 at 17:57 +0100, Stefan Kaltenbrunner wrote:
I thought the consensus was to provide the only atatype initially and
look into providing the generator functions later or via an external
project (pgfoundry or contrib/).
I don't think distributing the (portable) generator
Peter Eisentraut wrote:
Gevik Babakhani wrote:
So.. do we agree for uuid to be included in the core?
I suggest that you read the discussion in the tsearch thread about
figuring out how to make contrib modules more attractive. I don't see
a reason why uuid has to be in the core, but I do
Neil Conway wrote:
On Thu, 2007-01-25 at 17:57 +0100, Stefan Kaltenbrunner wrote:
I thought the consensus was to provide the only atatype initially and
look into providing the generator functions later or via an external
project (pgfoundry or contrib/).
I don't think distributing the
The MAC-based generator function could also be included in the backend,
actually: it just needs to take an argument of type macaddr. It would
then be up to the user (and/or various pgfoundry and contrib/ modules)
to find a way to determine the local machine's MAC address, which
presumably
I thought the consensus was to provide the only atatype initially and
look into providing the generator functions later or via an external
project (pgfoundry or contrib/).
This was my understanding too... to include the uuid in the core and let
the actual value be generated
On Jan 25, 2007, at 11:13 AM, Peter Eisentraut wrote:
I suggest that you read the discussion in the tsearch thread about
figuring out how to make contrib modules more attractive. I don't see
a reason why uuid has to be in the core, but I do see that there needs
to be some centrally organized
I'd be willing to accept a core uuid type sans generator function,
but is that really all that useful?
This is also a point I remember from the last discussions. To not to
include the generator in the core. The generation of the uuid is then
going to be on the client side.
The uuid type is
Gevik Babakhani wrote:
I'd be willing to accept a core uuid type sans generator function,
but is that really all that useful?
This is also a point I remember from the last discussions. To not to
include the generator in the core. The generation of the uuid is then
going to be on the client
But does it really help if you don't have the generator?
I don't use UUIDs much myself, but I think in all cases I've seen that
use the uuid type in SQL Server they're also using the generator function.
Those that just store UUIDs in the database often just uses varchar - in
order to be
Magnus Hagander wrote:
Gevik Babakhani wrote:
I'd be willing to accept a core uuid type sans generator function,
but is that really all that useful?
This is also a point I remember from the last discussions. To not to
include the generator in the core. The generation of the uuid is
Alvaro Herrera wrote:
Magnus Hagander wrote:
Gevik Babakhani wrote:
I'd be willing to accept a core uuid type sans generator function,
but is that really all that useful?
This is also a point I remember from the last discussions. To not to
include the generator in the core. The generation
Gevik Babakhani wrote:
There could be many algorithms to generate a guid. I guess we will
get into a big debate on that, which is not much useful i guess
(seeing the posts last year).
There are a handful of standardized or established algorithms, so it
doesn't hurt to provide them all.
On Fri, 2007-01-19 at 23:00 -0500, Tom Lane wrote:
Per previous discussion, the main problem with a uuid type is the
new-uuid generator function, which tends to involve a bunch of
not-so-portable assumptions and code.
RFC 4122 specifies several ways of generating UUIDs:
* via the computer's
On Sat, 2007-01-20 at 14:56 +0100, Gevik Babakhani wrote:
what is the next step now? is there going to be review by a committer?
if so, please note that the OIDs in the patch have to be changed.
I already suggested a few things you could improve in the patch. If this
discussion concludes that
I already suggested a few things you could improve in the patch. If this
discussion concludes that the patch should be included in the core
backend and you submit a revised patch, I'd be happy to review and apply
it.
So.. do we agree for uuid to be included in the core?
If so.. I will change
Hi,
While ago (sep-2006) I sent a patch for the UUID datatype, Did anyone
have time to review it yet?
Here it is again :)
Regards,
Gevik
*** ./backend/utils/adt/Makefile.orig 2006-09-19 12:05:41.0 +0200
--- ./backend/utils/adt/Makefile 2006-09-19 12:06:47.0 +0200
On Fri, 2007-01-19 at 10:25 +0100, Gevik Babakhani wrote:
While ago (sep-2006) I sent a patch for the UUID datatype, Did anyone
have time to review it yet?
I confess I haven't followed the discussion around this patch, but is
there a compelling reason to include this in the backend proper,
I confess I haven't followed the discussion around this patch, but is
there a compelling reason to include this in the backend proper, rather
than contrib/?
AFAIK, It is/was part of the TODO for the core.
---(end of broadcast)---
TIP 5: don't
On Sat, 2007-01-20 at 00:21 +0100, Gevik Babakhani wrote:
AFAIK, It is/was part of the TODO for the core.
Well, I don't have a strong opinion either way, but I think it should be
given some thought.
As far as the code, looks pretty good. A few minor comments:
* varchar_uuid() should be named
Neil Conway wrote:
On Sat, 2007-01-20 at 00:21 +0100, Gevik Babakhani wrote:
AFAIK, It is/was part of the TODO for the core.
Well, I don't have a strong opinion either way, but I think it should be
given some thought.
As far as the code, looks pretty good. A few minor comments:
*
On Fri, 2007-01-19 at 19:19 -0500, Bruce Momjian wrote:
I think having it in core makes the most sense.
Why is that?
One question that comes to mind is how the submitted patch compares in
functionality to the other implementations of the UUID concept for
PostgreSQL, such as OSSP uuid (which
Bruce Momjian wrote:
I should have been clearer. I think having in the main server or
/contrib makes sense. Having data types external to our source tree
doesn't seem to work too well because of changes in our API from time
to time.
When has the API for data types ever changed?
--
Peter
Peter Eisentraut wrote:
Bruce Momjian wrote:
I should have been clearer. I think having in the main server or
/contrib makes sense. Having data types external to our source tree
doesn't seem to work too well because of changes in our API from time
to time.
When has the API for data
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
When has the API for data types ever changed?
The API doesn't change, but the way to do things inside the type
functions does changes sometimes.
We've always done our best not to break user-defined datatypes without
need. uuid
Per previous discussion, the main problem with a uuid type is the
new-uuid generator function, which tends to involve a bunch of
not-so-portable assumptions and code. If we accept a uuid type in
either core or contrib, all of a sudden those portability issues are
our problem. I'd rather
Joshua D. Drake wrote:
Per previous discussion, the main problem with a uuid type is the
new-uuid generator function, which tends to involve a bunch of
not-so-portable assumptions and code. If we accept a uuid type in
either core or contrib, all of a sudden those portability issues are
our
30 matches
Mail list logo