Re: [HACKERS] Idea on how to simplify comparing two sets - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [HACKERS] Idea on how to simplify comparing two sets
Date
Msg-id 595203eb-73c3-cffa-7b7d-3f35d87e575a@BlueTreble.com
Whole thread Raw
In response to Re: [HACKERS] Idea on how to simplify comparing two sets  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Idea on how to simplify comparing two sets
List pgsql-hackers
On 2/7/17 12:03 PM, Tom Lane wrote:
>> That said I'm not sure how much we want to go down this road on our own.
>> It'd be nice to have when its needed but its not something that gets much
>> visibility on these lists to suggest a large pent-up demand.
> Yeah, if this isn't in the standard and not in other databases either,
> that would seem to suggest that it's not a big requirement.

FWIW I've found myself needing the precursor to this this (give me the 
full diff) at least a couple times, and it's quite a PITA on anything 
but a trivial relation.

It's also not possible to make this easier via an SRF because you don't 
know in advance what the result set looks like. So the best I've ever 
come up with is a file that can be included in psql that depends on 
having set two psql variables to the names of relations that can be 
queried (and if you need more than a relation you need to create a temp 
view).

I've wondered about the possibility of allowing PLs the ability to 
dynamically define their return type based on their arguments. That 
would allow for an SRF to handle this case, and would be significantly 
more flexible than trying to do that using pseudotypes.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] bytea_output output of base64
Next
From: Jim Nasby
Date:
Subject: Re: [HACKERS] PinBuffer() no longer makes use of strategy