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