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,
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
Henry
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
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 the
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 analyze the
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 ...
with both versions and send the results (preferably without line
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
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:
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 simply
not supportable. (For one thing, which actual record types
10 matches
Mail list logo
