RE: SQL Server -> Postgres migration: Stored Procedure replacement?
От | Eliel Mamousette |
---|---|
Тема | RE: SQL Server -> Postgres migration: Stored Procedure replacement? |
Дата | |
Msg-id | 000601c0d202$203b2b10$2001a8c0@blockhead обсуждение исходный текст |
Ответ на | Re: SQL Server -> Postgres migration: Stored Procedure replacement? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
"Tom Lane" <sss.pgh.pa.us> writes: > "Eliel Mamousette" <eliel@panix.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 >
В списке pgsql-general по дате отправления: