Bill Moran wrote:
Basically, all I do is call each query in turn until I've collected all the
results, then marshall the results in to a SOAP XML response (using gsoap,
if anyone's curious) and give them back to the client application. It's
the client app's job to figure out what to do with them,
Josh Berkus wrote:
Shridhar, Bill,
Is MSSQL allows to mix rows of two types in single function invocation,
I am sure that would be a hell lot of porting trouble..
There's also the question of whether or not PG would every want to do this.
Frankly, as a once-upon-a-time SQL Server application dev
Shridhar, Bill,
> > Is MSSQL allows to mix rows of two types in single function invocation,
> > I am sure that would be a hell lot of porting trouble..
There's also the question of whether or not PG would every want to do this.
Frankly, as a once-upon-a-time SQL Server application developer, I
Shridhar Daithankar wrote:
Josh Berkus wrote:
Bill,
Some functions they prototyped in MSSQL even return different types,
based
on certian parameters, I'm not sure how I'll do this in Postgres, but
I'll
have to figure something out.
We support that as of 7.4.1 to an extent; check out "Polymorphi
Josh Berkus wrote:
Bill,
Some functions they prototyped in MSSQL even return different types, based
on certian parameters, I'm not sure how I'll do this in Postgres, but I'll
have to figure something out.
We support that as of 7.4.1 to an extent; check out "Polymorphic Functions".
To my unders
Bill,
> Some functions they prototyped in MSSQL even return different types, based
> on certian parameters, I'm not sure how I'll do this in Postgres, but I'll
> have to figure something out.
We support that as of 7.4.1 to an extent; check out "Polymorphic Functions".
--
-Josh Berkus
Aglio Da
Shridhar Daithankar wrote:
Bill Moran wrote:
I have an application that I'm porting from MSSQL to PostgreSQL. Part
of this
application consists of hundreds of stored procedures that I need to
convert
to Postgres functions ... or views?
At first I was going to just convert all MSSQL procedures
Tom Lane wrote:
Bill Moran <[EMAIL PROTECTED]> writes:
At first I was going to just convert all MSSQL procedures to Postgres functions.
But now that I'm looking at it, a lot of them may be candidates for views. A
lot of them take on the format of:
SELECT a.cola, b.colb, c.colc
FROM a JOIN b JOIN
Bill,
> > SELECT a.cola, b.colb, c.colc
> > FROM a JOIN b JOIN c
> > WHERE a.prikey=$1
If your views are simple, PostgreSQL will be able to "push down" any filter
criteria into the view itself. For example,
CREATE view_a AS
SELECT a.cola, b.colb, c.colc
FROM a JOIN b JOIN c;
SELECT * FROM vi
Bill Moran <[EMAIL PROTECTED]> writes:
> At first I was going to just convert all MSSQL procedures to Postgres functions.
> But now that I'm looking at it, a lot of them may be candidates for views. A
> lot of them take on the format of:
> SELECT a.cola, b.colb, c.colc
> FROM a JOIN b JOIN c
> WH
Bill Moran wrote:
I have an application that I'm porting from MSSQL to PostgreSQL. Part
of this
application consists of hundreds of stored procedures that I need to
convert
to Postgres functions ... or views?
At first I was going to just convert all MSSQL procedures to Postgres
functions.
But
I have an application that I'm porting from MSSQL to PostgreSQL. Part of this
application consists of hundreds of stored procedures that I need to convert
to Postgres functions ... or views?
At first I was going to just convert all MSSQL procedures to Postgres functions.
But now that I'm looking a
12 matches
Mail list logo
