aye aye Sir.
--
GJ
If we knew what we were doing, it wouldn't be called Research, would
it? - AE
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Sat, 2005-11-19 at 12:22 -0500, Tom Lane wrote:
A better fix seems to require passing the TupleTableSlot, not just the
bare tuple, down to the toaster --- else there is no way for the toaster
to update the data structure that it's accidentally invalidating. This
seems like it might be a
On Sat, Nov 19, 2005 at 08:02:08PM -0300, Alvaro Herrera wrote:
Hmm -- probably we could declare that the current libpq API will not
support multiple result sets from one query, and return only the first
one to the application discarding the rest. (It just occured to me --
what happens if one
On Sun, Nov 20, 2005 at 08:43:05AM +0100, Pavel Stehule wrote:
Consider:
create function a(anyrecord) returns anyrecord;
create function b(int4) returns anyrecord;
select a(b(2));
for my task I need little different form :-(
create function a(..) returns setof tables
but SQL2003
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2005-11-19 at 12:22 -0500, Tom Lane wrote:
... The problem is that given the
current structure, that means changing the APIs of heap_insert and
heap_update, or else making near-duplicate versions that take a
TupleTableSlot instead of a bare tuple.
Martijn van Oosterhout kleptog@svana.org writes:
libpq supports it just fine. You do a PQsendQuery() and then as many
PQgetResult()s as it takes to get back the results. This worked for a
while AFAIK.
That only works if the caller is prepared to read each result serially,
and not (say) a row
On 11/20/2005 11:23 AM, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2005-11-19 at 12:22 -0500, Tom Lane wrote:
... The problem is that given the
current structure, that means changing the APIs of heap_insert and
heap_update, or else making near-duplicate versions that take a
Jan Wieck [EMAIL PROTECTED] writes:
On 11/20/2005 11:23 AM, Tom Lane wrote:
Assuming that the saved header values don't need to be recomputed if the
tuple doesn't need to be toasted at all, I think that toasting is
expensive enough so that recomputing those values is hardly noticed.
Yeah,
for my task I need little different form :-(
create function a(..) returns setof tables
but SQL2003 needs type table, and this can be solution
You want a function return entire tables at a time? Why bother when you
can just return rows and signal when the next table starts?
what is
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Oh, good point. I was thinking just about concurrent MERGEs. However,
it is more complicated than that. By definitaion you can not see
changes from other transactions while your statement is being run (even
if you increment
On Sun, Nov 20, 2005 at 11:29:39AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
libpq supports it just fine. You do a PQsendQuery() and then as many
PQgetResult()s as it takes to get back the results. This worked for a
while AFAIK.
That only works if the caller
On Sun, Nov 20, 2005 at 06:05:36PM +0100, Pavel Stehule wrote:
what is difference between rows with different structures and tables?
Tables are more logic. But I unlike function which returns setof tables.
This need data type table. I prefere normal clasic solution.
You're confusing syntax
Hello
I thinking about solution based on setof cursors. This solustion has three
big minus:
1. I can unpack cursors after finish of called procedure. If I get
exception, or long query, I can show nothing.
2. Old clients don't understand and don't unpack cursor. Statement call is
(+/-) ==
On Sat, 19 Nov 2005, Josh Berkus wrote:
Could you post it to the list? I'd be interested to take a look, though
I'm afraid don't have the time to work on it.
Yeah, I should put it up on pgFoundry. I'm not sure exactly where, though --
I don't want to launch a new project if it's not going to
unsubscribe
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Sat, 19 Nov 2005, Nicolas Barbier wrote:
You might want to take a look at the pages that I set up to track the
progress on my master's thesis:
url:http://www.nicolas.barbier.easynet.be/itsme/thesis/
especially the literature page:
Martijn van Oosterhout kleptog@svana.org writes:
On Sun, Nov 20, 2005 at 11:29:39AM -0500, Tom Lane wrote:
That only works if the caller is prepared to read each result serially,
and not (say) a row at a time in parallel.
Urk! I don't think anyone is suggesting that resultsets can be
?
The patch does most of the above. There's no utility yet to create the
special postmaster.pid file. Use echo readonly data/postmaster.pid
instead.
Here's the patch:
http://users.tkk.fi/~hlinnaka/pgsql/readonly-20051120.diff
- Heikki
---(end of broadcast
I've noticed that if a client uses PQexecParams, the query plan
appears to be identical to the plan chosen for PQprepare/PQexecPrepared,
which might not be as optimal as a plan chosen for PQexec. I can
understand the PQprepare case since the planner doesn't know what
parameters will actually be
Heikki Linnakangas [EMAIL PROTECTED] writes:
5. Don't try to write buffers with commit hint modifications. Just discard
them.
The performance costs of that alone are astonishing (ie, repeated
verifications of commit status).
I think what you are doing is a completely wrongheaded way to
On Sun, Nov 20, 2005 at 11:29:39AM -0500, Tom Lane wrote:
That only works if the caller is prepared to read each result
serially, and not (say) a row at a time in parallel.
Urk! I don't think anyone is suggesting that resultsets can be
interleaved.
No? If not, why not? The main
On Sun, Nov 20, 2005 at 03:41:36PM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Urk! I don't think anyone is suggesting that resultsets can be
interleaved.
No? If not, why not? The main reason why this is being pushed, IIRC,
is the claim that you can do this
On Sun, Nov 20, 2005 at 10:01:24PM +0100, Magnus Hagander wrote:
FWIW, MSSQL used to do only multiple sequential resultsets (from stored
procs, or semicolon separated statements). With SQL 2005, they added
interleaved ones - see
Michael Fuhr [EMAIL PROTECTED] writes:
I've noticed that if a client uses PQexecParams, the query plan
appears to be identical to the plan chosen for PQprepare/PQexecPrepared,
which might not be as optimal as a plan chosen for PQexec. I can
understand the PQprepare case since the planner
Hi
It seems that plpython is unable to return bytea string when it contains
NUL bytes:
hannu=# CREATE OR REPLACE FUNCTION get_bytea_with_nul() RETURNS bytea AS
'
return ''aa\\0bb''
' LANGUAGE plpythonu SECURITY DEFINER;
hannu=# select get_bytea_with_nul();
get_bytea_with_nul
On Sun, Nov 20, 2005 at 05:21:03PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Is PQexecParams just shorthand for a prepare followed by an execute?
Yes, but it uses the unnamed statement, so in recent server versions you
should get a postponed plan that uses the Bind
Michael Fuhr [EMAIL PROTECTED] writes:
Here's a simplified client program (the original has
error checking but I've stripped it out for brevity; this simplified
version behaves the same way):
I get the same results for all three after fixing the subscripting
mistake:
- values[1] =
On Sun, Nov 20, 2005 at 08:34:39PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Here's a simplified client program (the original has
error checking but I've stripped it out for brevity; this simplified
version behaves the same way):
I get the same results for all three
Heikki,
4. Don't increment xid counter, just use a single xid for all
transactions. Otherwise we might reach the xid wrap-around point, and we
can't vacuum. It seems safe to me, am I missing anything?
Well, it eliminates transaction isolation. Completely.
--
Josh Berkus
Aglio Database
Am Montag, den 21.11.2005, 02:11 +0200 schrieb Hannu Krosing:
Hi
It seems that plpython is unable to return bytea string when it contains
NUL bytes:
hannu=# CREATE OR REPLACE FUNCTION get_bytea_with_nul() RETURNS bytea AS
'
return ''aa\\0bb''
' LANGUAGE plpythonu SECURITY DEFINER;
30 matches
Mail list logo
