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 DEFINE
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 So
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 a
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] = "Fa
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 Bin
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
---
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
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
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
On Sun, Nov 20, 2005 at 03:41:36PM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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 easily in
> > 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 n
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 app
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 us
anyone remember anything else that writes to disk?
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/
Martijn van Oosterhout 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
> interleaved.
No?
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:
http://www.nicolas.barbier.easynet.be/itsme/thesis/>
especially the literature page:
http://www.nicolas.barbier.easynet.be/itsme/thesis/literature/
unsubscribe
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
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
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
(+/-) == sta
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
On Sun, Nov 20, 2005 at 11:29:39AM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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 prepa
Tom Lane wrote:
> Bruce Momjian 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 CommandCounter)
> 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 d
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.
Ye
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
Martijn van Oosterhout 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 at a time in par
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 b
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 tabl
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
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
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
30 matches
Mail list logo
