I want to write a stored procedure using aggregate functions. Is there some place where I could refer for this?
I couldn't find any concrete material.
Related
I am optimizing the search query in the Postgres database. The query uses the unaccent function.
I want to create a gin-index to make the search query faster. So I had gone through some articles on faking the stable function as an immutable function using wrapper functions.
I was thinking of creating a new column for precomputed unaccented texts would be good. But I got to know that the unaccent function can produce different outputs.
So what is the preferred way?
Precomputation or using a wrapper function to deceive the program?
I've a procedure in Oracle PL/SQL which fetches transactional data based on certain condition, then performs some logical calculations. I used cursor to store the SQL and then I used FETCH (cursor) BULK COLLECT INTO (table type variable) LIMIT 10000, iterated over this table variable to perform calculation and ultimately storing the value in a DB table. Once 10000 rows have been processed, query will be executed to fetch next set of records,
This helped me limiting number of times SQL is executed via cursor and limiting the number of records loaded into memory.
I am trying to migrate this code to plpgsql. How can I achieve this functionality in plpgsql?
You cannot achieve this functionality in PostgreSQL.
I wrote an extension https://github.com/okbob/dbms_sql . It can be used for reduce of necessary work related to migration from Oracle to Postgres.
But you don't need this feature in Postgres. Although PL/pgSQL is similar to PL/SQL, the architecture is very different - and bulk collect operations are not necessary.
How do I use Slick to call a stored procedure?
I want it to be type safe / injection safe. (ie, I don't want any SQL query strings in my code...)
According to the docs, Slick includes "Type-safe support of stored procedures" (http://slick.typesafe.com/doc/1.0.0/introduction.html)
But I do not see any example in the docs of how to do it.
That's a typo. It should read "Type-safe support of scalar database functions". At the moment you have to use plain SQL to call stored procedures.
Also see https://groups.google.com/forum/#!searchin/scalaquery/procedure/scalaquery/BUB2-ryR0bY/EFZGX663tRYJ
Right now I have two stored procedures that return data sets, and I'd like to create another stored procedure that executes both stored procedures and returns their combined datasets (to a .Net application).
Is this as simple as just running "EXEC" on both of the stored procedures or do I need to add in some logic that combines the two data sets?
You can just exec each SP one after the other and the application ('m assuming it's based on .NET) will see two result-sets. The results will not be combined into a single result though so you'll need to use DbDataReader.NextResult(): http://msdn.microsoft.com/en-us/library/system.data.common.dbdatareader.nextresult.aspx.
If you need the results to be combined into a single result as far as the application is concerned you'll need to insert the results of th SPs into two table-valued-variables and then SELECT-JOIN them.
Alternatively, and if possible, convert the two child SPs into table-valued functions and then SELECT-JOIN the results directly.
I need to make sure my ado.net commands don't return more than 1000-5000 rows. Is there an ADO.NET way to do this, or is it just a TSQL?
I'm calling a stored procedure, I don't control the source code in that stored procedure. Hence I was hoping there was a ADO.NET way to do it.
Before LINQ this typically was always done using a top N clause in your inline query or stored proc. With LINQ there is some cool functions called "Take" and "Skip" which provides a construct for downloading and or skipping N number of rows. Under the hood LINQ figures out the details of how to construct the inline query that yields the exact number of rows you want off the top.
[Edit]
Since you're calling a stored procedure, I'd advise just using a TOP N clause in the select statement. This is path of least resistance and IMHO is the simplest to maintain going forward since you already have the stored procedure.