Re: [SQL] Best way to "and" from a one-to-many joined table?

part with where a."attribute" in (@firstAttr,@secondAttr,...) For best results, you can index the field "attribute" on test_attributes table. Be aware of case sensitivity of PG text search. Best regards, Milan Oparnica Oliveiros Cristina wrote: Howdy, Bryce Could you please

Re: [SQL] JOIN results of refcursor functions

Milan Oparnica wrote: Then I've tried: CREATE FUNCTION foo(insklid int, out sklid int, out elid INT) RETURNS SETOF record AS $$ BEGIN RETURN QUERY SELECT sklid,elid FROM skladkol; RETURN; END; $$ LANGUAGE plpgsql; but it returns 5498 rows (which is exact number of rows in that

Re: [SQL] JOIN results of refcursor functions

Alvaro Herrera wrote: Milan Oparnica escribió: I've searched documentation (8.3) and didn't find a way to use OUT variables in same manner as SETOF (RETURN NEXT doesn't create a record type result). Can you please give an example of how to return select fld1, fld2 from ta

Re: [SQL] JOIN results of refcursor functions

Alvaro Herrera wrote: Milan Oparnica escribió: Tom Lane wrote: Milan Oparnica <[EMAIL PROTECTED]> writes: Is there any way to use INNER, LEFT and RIGHT JOIN between functions returning refcursor type. No. Make them return setof whatever instead. I would like yo avoid creating

Re: [SQL] JOIN results of refcursor functions

Tom Lane wrote: Milan Oparnica <[EMAIL PROTECTED]> writes: Is there any way to use INNER, LEFT and RIGHT JOIN between functions returning refcursor type. No. Make them return setof whatever instead. regards, tom lane I would like yo avoid creating custom com

[SQL] JOIN results of refcursor functions

select f1.a, f2.b from function1 as f1 inner join function2 as f2 on f1.a=f2.a; open f3; return f3; Thanks, Milan Oparnica. -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] PERSISTANT PREPARE (another point of view)

;s hope he does his implementation in 8.4. Regards, Milan Oparnica -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] PERSISTANT PREPARE (another point of view)

sult type must be specified ** Error ** ERROR: function result type must be specified SQL state: 42P13 Is this because of QueryTool's limitations or is this feature not yet implemented in Postgre ? Though, CREATE PROCEDURE should be a valid SQL 92 standard procedure. Be

Re: [SQL] PERSISTANT PREPARE (another point of view)

this way but its very usable for 99% of small and medium business apps (databases up to few gigabytes). It greatly depends on your internal database representation though. Best regards, Milan Oparnica -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] PERSISTANT PREPARE (another point of view)

, fetching records from cursor type SP requires transactional approach in calling convention (BEGINstatment...END). At this moment I don't know if this can be done in our main report designer tool - Business Objects (former Crystal Reports). Best regards, Milan Oparnica Here is

Re: [SQL] PERSISTANT PREPARE (another point of view)

Craig Ringer wrote: Milan Oparnica wrote: I found this link from IBM DB2 developers showing why PERSISTENT PREPARE is a good idea and how could it be implemented. [snip] NONE OF POPULAR SQL DBMS (Oracle, MS SQL, MySQL, Postgre, INTERBASE, FIREBIRD) HAVE THIS FEATURE. WHY ? I suspect

Re: [SQL] PERSISTANT PREPARE (another point of view)

I found this link from IBM DB2 developers showing why PERSISTENT PREPARE is a good idea and how could it be implemented. http://www.hoadb2ug.org/Docs/Favero20606.pdf It seems that main benefit (beside efficiency) is memory. Having number of connections all with dozens of PREPARED statements co

Re: [SQL] PERSISTANT PREPARE (another point of view)

Richard Huxton wrote: >> Milan Oparnica wrote: >> >>It's simply to complicated to return recordsets through >>server-side stored procedures. They are obviously designed to do >>complex data manipulation ... > Richard wrote: >I'm not

Re: [SQL] PERSISTANT PREPARE (another point of view)

Richard Huxton wrote: >> Milan Oparnica wrote: >> >>It's simply to complicated to return recordsets through >>server-side stored procedures. They are obviously designed to do >>complex data manipulation ... > Richard wrote: >I'm not

Re: [SQL] PERSISTANT PREPARE (another point of view)

Pavel wrote: try to write prototype and show advantages... Prototype of what, implementation into Postgre or just efficiency of PRESISTANT PREPARE idea ? ...but I see some disadvatage too. Mainly you have to manage some shared memory space for stored plans. It's not easy task - MySQL dev

Re: [SQL] PERSISTANT PREPARE (another point of view)

Milan Oparnica wrote: It's simply to complicated to return recordsets through server-side stored procedures. They are obviously designed to do complex data manipulation, returning few output variables informing the caller about final results. Returning records through sets of user-de

Re: [SQL] PERSISTANT PREPARE (another point of view)

ocally for the user. Is it possible to take it globally, for all users, and not to forget it when all connections dye? It is a way to get all of SQL statement out of the application not only "as much logic as you can". As a leader of our development team I find it HIGHLY (and I mean

Re: [SQL] PERSISTANT PREPARE (another point of view)

n minutes you can produce a profit&loss by sectors, or by employees or whatever. What is the magic part, if we introduce new type of documents to our program that do influence profit&loss then we simply change the BASE prepared statement. And ALL reports based on it get "upgraded&q

[SQL] PERSISTANT PREPARE (another point of view)

ms with tons of data, but is very efficient in 90% of small and medium business size databases. Please consider this issue when planning your WISH LIST or hopefully To-do-task-list. Ill be glad to here comments on this topic as well.