> > 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.
My experiences are similar. At the moment, I'm resigned to using relying on pgtap: -- set environment/path to point to "control" create temporary table test_1_wants as <query of table or function as it was>; -- set environment/path to point to "experiment" create temporary table test_1_has as <query of thing we're trying to test now>; select results_eq( 'table test_1_has', 'table test_1_wants', 'test 1'); I've had to do it with temp tables any time the environment is different between control/experiment, which is the case when you're developing a drop-in replacement for an SRF or view or whatever.
