Hi everybody. Can anyone enlighten me what's wrong with this function :
CREATE OR REPLACE FUNCTION month_year(mon integer, intv integer, OUT
ro integer, OUT mi integer)
RETURNS SETOF record AS
$BODY$
DECLARE
w record;
cy integer := EXTRACT (YEAR FROM current_date);
BEGIN
FOR w IN
The function behaves as expected when in plain SQL, only plpgsql
function has the above mentioned problem.
regards
mk
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
2008/8/4 Marcin Krawczyk <[EMAIL PROTECTED]>
> Hi everybody. Can anyone enlighten me what's wrong with this function :
>
> CREATE OR REPLACE FUNCTION month_year(mon integer, intv integer, OUT
> ro integer, OUT mi integer)
> RETURNS SETOF record AS
> $BODY$
> DECLARE
> w record;
> cy in
Dzieki za odpowiedz. Ciekawe ze funkcja SQL dziala bez problemu - ale
tu juz trzeba wskazac parametry OUT.
Thanks for your answer. It's curious that SQL function works as
expected - but requires OUT params.
pozdrowienia/regards
mk
2008/8/4 Pawel Socha <[EMAIL PROTECTED]>:
>
>
> 2008/8/4 Marcin
In the application that we are working on, all data searches must be case
insensitive.
Select * from test where column1 = 'a' and Select * from test where column1 =
'A' should always be the same and use the index if column1 is indexed. In
order to do this am I going to be required to us
"Pawel Socha" <[EMAIL PROTECTED]> writes:
> 2008/8/4 Marcin Krawczyk <[EMAIL PROTECTED]>
>> Hi everybody. Can anyone enlighten me what's wrong with this function :
> [ you didn't do "RETURN next w;" ]
IIRC the other way is to assign to the output parameters by name, then
do RETURN NEXT with no ar
On Mon, Aug 4, 2008 at 6:54 AM, Mike Gould <[EMAIL PROTECTED]> wrote:
>In some db's if you
> use a lower() or upr() it will always do a table scan instead of using a
> index
True, this would also happen in PostgreSQL. However, you can overcome
this by creating a "functional" index:
http://www.po
On Monday 04 August 2008 10:05, Richard Broersma wrote:
> On Mon, Aug 4, 2008 at 6:54 AM, Mike Gould <[EMAIL PROTECTED]> wrote:
> >In some db's if you
> > use a lower() or upr() it will always do a table scan instead of using a
> > index
>
> True, this would also happen in PostgreSQL. However, you
Terry Lee Tucker wrote:
On Monday 04 August 2008 10:05, Richard Broersma wrote:
On Mon, Aug 4, 2008 at 6:54 AM, Mike Gould <[EMAIL PROTECTED]> wrote:
In some db's if you
use a lower() or upr() it will always do a table scan instead of using a
index
True, this would also happen in PostgreSQL.
On Monday 04 August 2008 11:09, Frank Bax wrote:
> Terry Lee Tucker wrote:
> > On Monday 04 August 2008 10:05, Richard Broersma wrote:
> >> On Mon, Aug 4, 2008 at 6:54 AM, Mike Gould <[EMAIL PROTECTED]> wrote:
> >>> In some db's if you
> >>> use a lower() or upr() it will always do a table scan ins
Hi!
I have to do much inserts into a database where the key most often is
already there.
My current approach is to query for the key (ip-address), and if the
result is null I do the insert.
For every IP-Address I need the ip_addr_id from the same table.
Something like this:
CREATE TABLE ip_addr
Patrick Scharrenberg, 04.08.2008 17:51:
Hi!
I have to do much inserts into a database where the key most often is
already there.
My current approach is to query for the key (ip-address), and if the
result is null I do the insert.
For every IP-Address I need the ip_addr_id from the same table.
[
On Mon, Aug 4, 2008 at 8:51 AM, Patrick Scharrenberg <[EMAIL PROTECTED]> wrote:
> My current approach is to query for the key (ip-address), and if the
> result is null I do the insert.
> For every IP-Address I need the ip_addr_id from the same table.
>INSERT INTO ip_addre
13 matches
Mail list logo
