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
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.
[
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
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
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 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
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
"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
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
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
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
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
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
13 matches
Mail list logo
