Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Arrays of Complex Types

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Fetter <david(at)fetter(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Arrays of Complex Types
Date: 2007-04-08 22:47:44
Message-ID: 46197110.8000208@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
>   
>> On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
>>     
>>> So, hum, what happened to the idea of creating the array types only
>>> on demand?
>>>       
>
>   
>> Scotched, as far as I could tell,
>>     
>
> More like "you submitted a patch that entirely ignores multiple people's
> opinion on what is needed".
>
> Bruce may have put this into the patch queue, but do not labor under
> the delusion that that means it'll get applied as-is.  The queue is
> currently operating as a list of open issues.
>
>   

One of the things that's been bothering me about this proposal is that 
it leaves untouched and indeed greatly expands the scope of the typename 
mangling we do. (i.e. adding an entry to pg_type with _ prepended). Up 
to now we've only used this gadget in a way that might matter a lot on 
user defined non-composite types, I think, and now we have expanded that 
to include enums, which are really a special case of user defined 
non-composites which don't require an extra C module. That's a 
comparatively small window, but this proposal will extend it to all 
composites, which is quite a large expansion in scope. And since _ is a 
perfectly legal initial char for an identifier, if type _foo exists then 
any attempt to create a table or view or composite called foo will fail.

Is it possible to fix this, or am I trying to shut the stable door after 
the horse has well and truly bolted? If it can be fixed, I'd like to see 
it fixed before we fix the problem David is trying to address here.

It's been suggested to me that this is an insignificant corner case. But 
I have often seen coding standards that actually require certain classes 
of identifier to being with _, so it's very far from a merely 
theoretical point.

I'm slightly inclined to agree with David that the danger of catalog 
bloat isn't that great, and might not justify the extra work that some 
sort of explicit array creation would involve (e.g. changes in grammar, 
pg_dump), as long as we are agreed that we don't want array types ever 
to have their own user definable names or settable namespace.

cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-08 23:08:38
Subject: Re: [HACKERS] Arrays of Complex Types
Previous:From: Peter EisentrautDate: 2007-04-08 19:38:57
Subject: Re: problem with install scripts.

pgsql-patches by date

Next:From: Tom LaneDate: 2007-04-08 23:08:38
Subject: Re: [HACKERS] Arrays of Complex Types
Previous:From: Simon RiggsDate: 2007-04-08 21:24:51
Subject: Minor recovery changes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group