On Wed, 21 Sep 2005, Sean Davis wrote:
I have a table like:
Create table gf (
pkserial,
start int,
end int,
gfvarchar
);
I want to do queries along the lines of:
find all gf that overlap with (1,2) or
find all gf that overlap with each other
And
I find store functions fairly useful; eg for any table 'foo', the function
store_foo(v1,v2,...,vn) returns int;
will perform an insert (if a unique key is not present) or an update (if
the unique key is present)
v1,...,vn may be values for columns in the table foo, or perhaps also for
tables
, and not have my code break with some future postgres
version.
What are the reasons for deprecating the use of the function in the
SELECT clause? Am I missing something obvious?
Thanks for any insight
--
Chris Mungall
---(end of broadcast)---
TIP 4: Have
On Mon, 1 Aug 2005, Tom Lane wrote:
Chris Mungall [EMAIL PROTECTED] writes:
What are the reasons for deprecating the use of the function in the
SELECT clause?
The semantics of having more than one set-returning function in the
target list are, um, poorly thought out. However, we haven't
