Re: [HACKERS] [DOCS] uuid type not documented

# [EMAIL PROTECTED] / 2007-04-10 15:49:08 -0400: > Neil Conway wrote: > >On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote: > > > >>The problem is that most of the standard methods are platform dependent, > >>as they require MAC addresses or a "good" random source, for instance. > >>

Re: [HACKERS] UUID generation functions

# [EMAIL PROTECTED] / 2007-04-11 14:27:47 +0200: > I have built some UUID generation functions using the library at > . This should cover all the usual ways to > do it, and it also provides some special constants that could be useful. There's already a mapping

Re: [HACKERS] 8.2 features status

# kleptog@svana.org / 2006-08-05 15:49:33 +0200: > On Fri, Aug 04, 2006 at 06:25:35PM -0700, Joshua D. Drake wrote: > > I have heard you make this argument before, and it is just is not true. > > Even Debian is moving toward a more formal structure as has FreeBSD. You > > seem stuck in this world

Re: [HACKERS] ipcclean in 8.1 broken?

# [EMAIL PROTECTED] / 2006-03-01 12:49:13 +0100: > Am Dienstag, 28. Februar 2006 07:42 schrieb Christopher Kings-Lynne: > > I just tried using ipcclean in 8.1.3. It doesn't work when I su to the > > pgsql user. This part of the script: > > > > if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ] > > >

Re: [HACKERS] FreeBSD ICU was Win32 unicode vs ICU

# [EMAIL PROTECTED] / 2005-08-25 04:53:47 +1000: > Kevin McArthur Wrote: > > > Should the postgresql project also be looking at CLDR for > > cross-platform unicode support? > > Afaict, from the ICU website, ICU too uses CLDR. > Why reinvent the wheel? Just a thought: PHP is under a BSD-like

Re: [HACKERS] FreeBSD ICU was Win32 unicode vs ICU

# kleptog@svana.org / 2006-03-26 15:53:24 +0200: > On Sun, Mar 26, 2006 at 02:13:28PM +0200, Roman Neuhauser wrote: > > > Afaict, from the ICU website, ICU too uses CLDR. > > > Why reinvent the wheel? > > > > Just a thought: PHP is under a BSD-like (Apache-

Re: [HACKERS] uuid type for postgres

# [EMAIL PROTECTED] / 2005-09-06 17:54:34 -0400: > There's a fair amount of nearly > unmaintained cruft in the core distro already (eg, the never-finished > "line" datatype ... or the entire rtree index module ...) and a datatype > that might be used by only a few people is a likely candidate to be

[HACKERS] bug #1702: nested composite types in plpgsql

Hello, I'm getting this error with the code below (on 8.0.3 like the other guy in #1702. Is this a hard problem to fix? Looking at src/pl/plpgsql/src/pl_exec.c for the first time, is it a problem of make_tuple_from_row() not accounting for nested composite types? test=# SELECT takes_ct2parts(1, A

Re: [HACKERS] bug #1702: nested composite types in plpgsql

# [EMAIL PROTECTED] / 2005-09-13 12:17:06 -0400: > Roman Neuhauser <[EMAIL PROTECTED]> writes: > > Looking at src/pl/plpgsql/src/pl_exec.c for the first time, is it a problem > > of make_tuple_from_row() not accounting for nested composite types? > > Looks that way. I