RE: SQL Server -> Postgres migration: Stored Procedure replacement?

"Tom Lane" <sss.pgh.pa.us> writes:
> "Eliel Mamousette" <eliel(at)panix(dot)com> writes:
[question re: returning rows deleted to conserve bits]
>
> You don't specify more than one return type --- you specify one return
> type that is a composite type. Composite types are currently tied to
> tables; creating a table also creates a type that represents one of its
> rows. Thus
>
> create table foo (a int, b int, c int);
> create function foobar (...) returns foo as ...

Does rule also apply to views?

For example, what is the best practice when one doesn't want to return
a whole row? Given the restriction as stated, if I only wanted to
return column a and c from the table above, would I create a view
fooview and then say that function foobarview returns fooview?

If I write a paragraph about this process, to whom should I mail it for
inclusion in the documentation? I imagine it will be a FAQ for we who
are striving to escape from the legacy of Sybase and Microsoft's SQL
Server....

> Note that there are some annoying syntactic limitations on what you can
> actually *do* with a function returning tuples. We have plans to
> improve that situation in 7.2 or beyond, but for now, this facility
> isn't nearly as useful as one might think.

Thanks Tom, but can you be a bit more specific about what one can't do
with returned tuples? It might save some folks (and me) some time.

thanks again, this process has been extremely helpful,
eliel

> regards, tom lane
>