Re: Oid registry

From: "David Johnston" <polobo(at)yahoo(dot)com>
To: "'Robert Haas'" <robertmhaas(at)gmail(dot)com>, "'Andrew Dunstan'" <andrew(at)dunslane(dot)net>
Cc: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Oid registry
Date: 2012-09-27 17:08:13
Message-ID: 01bc01cd9cd2$ae748730$0b5d9590$@yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> > I did like the alternative idea upthread of UUIDs for types which
> > would give them a virtually unlimited space.
>
> Yeah, me too. That doesn't require a centralized authority (hence, no
> debates here about whether a given extension is important enough to merit
> an allocation of a given size), doesn't move us further in the direction
of
> exposing the database's internal identifiers as a concept that users have
to
> care about, ad provides essentially infinite address space. There's more
> engineering work involved but sometimes more engineering work means a
> better result.
>

Random thought from the sideline...

GIT is able to provide assurances as to content because it creates a hash.
Now, for a function PostgreSQL could hash the catalog entry (including
function body) and return than as proof that said function is the same as
one installed in some other database or published publically. I do not know
enough about the other objects to know if something similar is possible but
maybe this will spark someone else's thoughts.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2012-09-27 18:02:14 Re: psql, remove include of psqlscan.c
Previous Message Noah Misch 2012-09-27 16:56:52 Re: [PATCH] Support for Array ELEMENT Foreign Keys