Re: proposal: row_to_array function - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: proposal: row_to_array function
Date
Msg-id 5589C575.6080702@BlueTreble.com
Whole thread Raw
In response to Re: proposal: row_to_array function  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: proposal: row_to_array function  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
On 6/23/15 3:22 PM, Merlin Moncure wrote:
> I would rephrase that to: "do X to all fields of an object".
> Array handling is pretty good now (minus arrays of arrays, but arrays

Except that still won't make it easy to do something to each element of 
an array in SQL, which I think would be nice to have.

> of objects containing arrays is 'good enough' for most real world
> cases).  We've suffered for a while now with hstore/json as a
> temporary container to handle operations that are not well supported
> by postgres's particularly strongly typed flavor SQL.   The "OO" of
> postgres has been gradually diluting away; it's not a 'object
> relational' database anymore and the OO features, very much a product
> of the silly 90's OO hysteria, have been recast into more useful
> features like inheritance and/or pruned back.

Admittedly I've never played with an OO database, but I think our data 
features are pretty good [1]. Where I do think we can improve though is 
developing/coding things in the database. For example, I'd love to have 
the equivalent to a class. Perhaps that could be accomplished by 
allowing multiple instances of an extension. I'd also like stronger 
support for private objects (permissions don't really fit that bill).

> I don't mind having to push everything to jsonb and back for tuple
> manipulation and I expect that's how these types of things are going
> to be done moving forwards. jsonb has clearly caught a bid judging by
> what I'm reading in the blogosphere and will continue to accrete
> features things like this.

I think it's unfortunate to lose the strong typing that we have. That 
can be especially important for something like numbers (was it 
originally a float or a numeric?). But maybe JSON is good enough.


[1] The one OO-ish data feature I'd like is the ability to de-reference 
a foreign key "pointer". So if

CREATE TABLE b( a_id int REFERENCES a);

then have

SELECT a_id.some_field FROM b;

transform to

SELECT a.some_field FROM b JOIN a ...;
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: row_to_array function
Next
From: Jim Nasby
Date:
Subject: Re: proposal: row_to_array function