Re: SQL Server -> Postgres migration: Stored Procedure replacement? - Mailing list pgsql-general

From Roger Wernersson
Subject Re: SQL Server -> Postgres migration: Stored Procedure replacement?
Date
Msg-id 3AF83B71.1C8DDDFA@mindark.com
Whole thread Raw
In response to RE: SQL Server -> Postgres migration: Stored Procedure replacement?  ("Eliel Mamousette" <eliel@panix.com>)
Responses Max simultaneous users  (webb sprague <wsprague@o1.com>)
List pgsql-general
You just use a view. Period.

CREATE VIEW foobarview AS SELECT a, c FROM foo;

What else do you need?

CREATE VIEW foobarview AS SELECT a*2 AS double, b*c AS multiple,
max(a,c) AS maximum FROM foo;

I believe views does it all.

/Roger

Eliel Mamousette wrote:
>
> "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
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

pgsql-general by date:

Previous
From: Karl DeBisschop
Date:
Subject: Re: ER diagrams
Next
From: Andrew Perrin
Date:
Subject: PL/Perl without shared libperl.a