2010/12/15 Dmitriy Igrishin <dmit...@gmail.com> > > > 2010/12/15 Pavel Stehule <pavel.steh...@gmail.com> > > 2010/12/15 Dmitriy Igrishin <dmit...@gmail.com>: >> > >> > >> > 2010/12/15 Florian Pflug <f...@phlo.org> >> >> >> >> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote: >> >> > 2010/12/15 Florian Pflug <f...@phlo.org> >> >> > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote: >> >> > >> 2010/12/15 Florian Pflug <f...@phlo.org> >> >> > >> On Dec15, 2010, at 02:14 , James William Pye wrote: >> >> > >> > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote: >> >> > >> >> how do you identify which type OID is really hstore? >> >> > >> > >> >> > >> > How about an identification field on pg_type? >> >> > >> > >> >> > >> > CREATE TYPE hstore ..., IDENTIFIER 'org.postgresql.hstore'; >> >> > >> > -- Where the "identifier" is an arbitrary string. >> >> > >> >> >> > >> I've wanted something like this a few times when dealing >> >> > >> with custom types within a client. A future protocol version >> >> > >> might even transmit these identifiers instead a the type's OID, >> >> > >> thereby removing the dependency on OID from clients entirely. >> >> > > >> >> > > In some another tread I've proposed CREATE TYPE ... WITH OID... >> >> > Yeah, and I believe type identifiers are probably what you were >> >> > really looking for ;-) >> >> > Indeed, but why OID cannot serve as identifier in this case ? Why to >> >> > encode the code ? :-) >> >> Because there are only 2^32 OIDs, so if people start picking them at >> >> random, sooner or later there will be collisions. >> > >> > Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten >> > millions, e.g. can be enough. >> > >> >> >> >> > Type identifiers would solve >> >> > this, by providing an easy and unambiguous way to find specific >> types. >> >> > Agree with 1st assertion but disagree with 2nd. If I understand >> >> > correctly, >> >> > "identifier" is a second name for type (object), but Java-styled, >> right >> >> > ? >> >> > It probably does solve the problem if there are will be convention >> that >> >> > types org.postgresql.* are reserved. >> >> Yeah, that'd be the idea. If everyone uses reversed DNS-style names, >> and >> >> everyone picks a name belonging to a DNS zone under his control, there >> >> cannot be any collisions. At least for java packages, this seems to >> work >> >> pretty nicely. >> >> >> >> > But why not reserve name of type >> >> > "hstore" and prevent the user to create type with this reserved name >> ? >> >> > All this tells me one thing - to avoid conflicts of naming of >> specific >> >> > types >> >> > it is necessary to make them built-in. >> >> None of these solutions scale well. >> > >> > Well, If there are will be identifiers for each type, e.g. >> > org.postgresql.integer, why >> > they need to be built-in ? For "historical reasons" ? :-) >> > Let them also be in contribs... >> >> some types are used in system tables, so without support of these >> types, then you can't to add a new types. It's a egg-chicken problem >> > So, the formal criterion to make the type built-in is "the type is must be > primitive" ? > I.e. "the type for deploying system catalogs".
> >> Pavel >> >> >> >> >> best regards, >> >> Florian Pflug >> >> >> >> >> > >> > >> > >> > -- >> > // Dmitriy. >> > >> > >> > >> > > > > -- > // Dmitriy. > > > -- // Dmitriy.
