Greetings,
I gather the following isn't possible (which would have been elegant
and ideal):
FOR rec IN
FETCH 10 FROM cursor
LOOP
...
Anyone know the most efficient way of FETCHing a batch of rows, and
looping through them in a function? FETCHing a record at a time will
work, bu
Anyone know the most efficient way of FETCHing a batch of rows, and
looping >> through them in a function? FETCHing a record at a
time will work, but I >> was wondering whether this could be done.
You're outsmarting yourself.
:-) One can only try.
plpgsql already does the equivalent of
Hello
Searched around, but could not find this mentioned.
I've noticed the following behaviour in 7.4.5:
[explain analyse] select * from foo where
col1 = 1 or
col1 = 2 or
col1 = 3 or
col1 = 4 or
col1 = 5 or
col1 = 6 or
col1 = 7 or
col1 = 8;
where an index on foo.col1 exists.
The above works fi
>
> Check the estimated number of rows returned. It's presumably believing
> that the a sequential scan will be cheaper for the estimated number of
> rows.
>
> If the estimated number of rows is significantly off, you may wish to
> change the statistics target (see ALTER TABLE) for col1 and analyz
> "Henry Combrinck" <[EMAIL PROTECTED]> writes:
>
>> The above works fine - the index is used. However, extend the where
>> clause with an extra line (say, col1 = 9) and the index is no longer used.
>
> Do
>
> explain analyze select ...
>
>
Hello all
I've been approached by the development people about removing the 'public'
schema. They complain about having to manually remove the 'public_' tag
from table names generated by their development software whenever they
link to PG via ODBC.
Renaming or using another schema is not what th
> It sounds to me like the real problem is with non-schema-aware client
> software.
They're using Office XP Developer (Access 2000). No hope of fixing that.
> ...I think your options are to fix that, or downgrade to a
> non-schema-aware database (eg. Postgres 7.2 or before).
...and miss out on
> No problem at all.
> It's easy to automate the table linking process.
>
> I have a table in access that holds - among other things - the internal
> and external name of my linked tables, in which database, schema and
> server they locate.
[snip]
Thank you very much for the information.
Regards
Hello
Hopefully someone can shed some light on the following issue. After
chatting at irc.freenode.net/#postgresql, without success, this is my last
effort before giving up and using a temp table.
Essentially, I would like to pass a RECORD variable from one function to
another using plpgsql:
fu
> "Henry Combrinck" <[EMAIL PROTECTED]> writes:
>> Essentially, I would like to pass a RECORD variable from one function to
>> another using plpgsql:
>
>> func2(record)
>
> You can't declare a plpgsql function that accepts RECORD; this is simp
10 matches
Mail list logo