Fujii Masao wrote:
This assertion failure derives from the recent refactoring of ReadRecord().
Which changed the startup process so as to re-fetch the last applied WAL
record at the end of recovery from the buffer instead of the WAL file if it's
stored in the buffer. In this case, the last
On 1/18/2010 4:42 PM, Tom Lane wrote:
I think including MSVC in the set of compilers targeted by a configure
test is just a waste of code. It's more likely to confuse people than
help them.
Ok, I have taken that out, and instead put the right stuff for MSVC into
pg_config.h.win32.
Regards,
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
On mån, 2010-01-18 at 16:34 -0800, Kurt Harriman wrote:
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of __inline.
Hmm, but forceinline is not the same as inline. Are we confident
Hi all,
while testing the seq scan + sort CLUSTER implementation, I've found a
bug in write/readtup_rawheap.
The functions are needed by the sort part.
The code in
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php
didn't copy the whole tuple, but only the HeapTuple header:
On Wed, Feb 10, 2010 at 4:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, so after running restore_command, check the file size and if it's
too short, treat it the same as if restore_command returned non-zero?
Yes, only in standby mode case. OTOH I think that normal
On 1/19/2010 8:01 AM, Peter Eisentraut wrote:
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
We have some existing inline functions in .c files. These can be
more complicated, so it might be ok if the compiler decides to
leave them
On 12/16/2009 8:40 AM, Tom Lane wrote:
Alvaro Herreraalvhe...@commandprompt.com writes:
IIRC Kurt was also on about getting rid of some ugly macros that could
instead be coded as inline functions (fastgetattr for example)
I'd just bounce that as useless activity. If they are macros now,
and
On 2010-02-10 03:20 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-02-10 02:19 +0200, Tom Lane wrote:
You still haven't explained why it's a good idea to change the snapshot
after the executor has started. Right at the moment I'm prepared to
reject the
On 12/16/2009 8:21 AM, Tom Lane wrote:
I would only suggest that the cleanest coding would be
#ifdef USE_INLINE
static inline foo(...) ...
#else
... non-inline definition of foo
#endif
ie, go ahead and rely on autoconf's definition (if any) of inline
On Wed, Feb 10, 2010 at 3:59 AM, Robert Haas robertmh...@gmail.com wrote:
Yes. We could add every bell and whistle imaginable to the text
format and it still would not begin to approach the verbosity of the
machine-readable formats. Have you looked at them on a complex plan?
They are really,
We want to teach people that Hot Standby and Streaming Replication are
two different features. However, Streaming Replication calls its main
parameter standby_mode which reminds more of Hot Standby than of
Streaming Replication.
People could also run a warm standby without streaming replication,
Joachim Wieland wrote:
We want to teach people that Hot Standby and Streaming Replication are
two different features.
I'm not sure about that, actually. Now that they're both in the tree,
they work nicely together and many users will think of them as one.
However, Streaming Replication calls
On 09/02/2010 23:37, Greg Smith wrote:
[snip]
So the logical choice is plain LGPL3. I am open to motivated
suggestions about other
licenses but I'll ignore such crap as BSD is more open than LGPL.
I agree with your general logic and while I can't speak for everyone, I
would be happy
Leonardo F wrote:
static void
writetup_rawheap(Tuplesortstate *state, int tapenum, SortTuple *stup)
{
HeapTupletuple = (HeapTuple) stup-tuple;
I think you're confusing HeapTuple and HeapTupleHeader. SortTuple-tuple
field should point to a HeapTupleHeader, not a HeapTuple.
The right
I think you're confusing HeapTuple and HeapTupleHeader. SortTuple-tuple
field should point to a HeapTupleHeader, not a HeapTuple.
Mmh, I don't get it: that would mean I might be using more info than required,
but I still don't understand why it's not working... at the end, CLUSTER is
going
to
On Wed, Feb 10, 2010 at 5:39 AM, Greg Stark st...@mit.edu wrote:
On Wed, Feb 10, 2010 at 3:59 AM, Robert Haas robertmh...@gmail.com wrote:
Yes. We could add every bell and whistle imaginable to the text
format and it still would not begin to approach the verbosity of the
machine-readable
Hi!
This patch enables showing configure status at the end of ./configure
run and thus makes ./configure process a bit easier to follow (in the
sense of what features are actually enabled).
Päikest,
Priit
From c6ab747e581c7ebeb954b2ccb4dbd932e1a61de7 Mon Sep 17 00:00:00 2001
From: Priit Laes
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [100210 02:33]:
Hmm, so after running restore_command, check the file size and if it's
too short, treat it the same as if restore_command returned non-zero?
And it will be retried on the next iteration. Works for me, though OTOH
it
I think I've found the problem:
tuple-t_data wasn't at HEAPTUPLESIZE distance from tuple.
I guess the code makes that assumption somewhere, so I had
to do:
tuple-t_data = (HeapTupleHeader) ((char *) tuple +
HEAPTUPLESIZE);
Now that
On Wed, Feb 10, 2010 at 1:26 PM, Robert Haas robertmh...@gmail.com wrote:
For example, EXPLAIN (VERBOSE, FORMAT JSON) is often ridiculously
wide because each output list is printed on a single line.
Perhaps this is just a terminology difference but it seems
ridiculously *narrow* to me:
On Wed, Feb 10, 2010 at 9:09 AM, Greg Stark st...@mit.edu wrote:
Perhaps this is just a terminology difference but it seems
ridiculously *narrow* to me:
Try select * from pg_class.
Or as I said at the time... nobody liked anything about the patch
except that they didn't have to write it.
I
Robert Haas robertmh...@gmail.com writes:
I sort of assumed we might get some feedback from pgadmin or other
tool writers between the time this was committed six months ago and
now, but I haven't seen a single message from anyone who has actually
tried to write a tool. As you imply, I think
Kurt Harriman harri...@acm.org writes:
On 1/19/2010 8:01 AM, Peter Eisentraut wrote:
One principle that I suppose should have been made more explicit is that
-- in my mind -- we should avoid littering our code with nonstandard
constructs in place of standard constructs.
Everyone seems to
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Is it a TODO item to replace DROP into DROP IF EXISTS
for cleanup commands in pg_restore?
No. We try to avoid using nonstandard SQL in dumps.
regards, tom lane
--
Sent via pgsql-hackers mailing list
2010/2/9 Magnus Hagander mag...@hagander.net:
On Tue, Feb 9, 2010 at 17:11, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Here's a patch that fixes this. I put it locally for the radius
authentication for now, since we don't use this anywhere else. Should
we
Magnus Hagander mag...@hagander.net writes:
If someone didn't notice, I have applied that fix and it appears to
have solved it.
... and there was much rejoicing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Hans-Jürgen Schönig wrote:
hi,
this patch implements SQL side tracing / tracking of statements and
statement execution times.
it is primarily intended to allow programmers to gather information
about the runtime behavior of a program and to figure out easily
where the bottlenecks are.
i
On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I sort of assumed we might get some feedback from pgadmin or other
tool writers between the time this was committed six months ago and
now, but I haven't seen a single message from
On Wed, Feb 10, 2010 at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Is it a TODO item to replace DROP into DROP IF EXISTS
for cleanup commands in pg_restore?
No. We try to avoid using nonstandard SQL in dumps.
How often do we succeed?
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
We try to avoid using nonstandard SQL in dumps.
How often do we succeed? It seems unlikely that our dumps would
be restorable into any other database.
When we were running in a mixed environment we had several
Kevin Grittner escribió:
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
We try to avoid using nonstandard SQL in dumps.
How often do we succeed? It seems unlikely that our dumps would
be restorable into any other database.
When we were running in a
On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I sort of assumed we might get some feedback from pgadmin or other
tool writers between the time this was
Robert Haas escribió:
On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I sort of assumed we might get some feedback from pgadmin or other
tool writers between the time this was committed six months ago and
now, but I haven't
Alvaro Herrera alvhe...@commandprompt.com writes:
Kevin Grittner escribió:
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
We try to avoid using nonstandard SQL in dumps.
How often do we succeed? It seems unlikely that our dumps would
be restorable into any
Dave Page dp...@pgadmin.org writes:
On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We can still hope that some feedback comes in during beta.
I'm not opposed to that in principal, but in practice
Aidan Van Dyk wrote:
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [100210 02:33]:
Hmm, so after running restore_command, check the file size and if it's
too short, treat it the same as if restore_command returned non-zero?
And it will be retried on the next iteration. Works for
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Kevin Grittner escribi�:
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
We try to avoid using nonstandard SQL in dumps.
How often do we succeed? It seems unlikely that our dumps would
On Wed, Feb 10, 2010 at 4:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We can still hope that some feedback comes in
Tom Lane escribió:
Dave Page dp...@pgadmin.org writes:
On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We can still hope that some feedback comes in during beta.
I'm not opposed to that in
On Wed, Feb 10, 2010 at 11:58 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane escribió:
Dave Page dp...@pgadmin.org writes:
On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We can
Robert Haas escribió:
On Wed, Feb 10, 2010 at 11:58 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Is Redhat's Visual Explain still alive? And what about Tom Raney's stuff?
The core of Tom Raney's work was not so much the EXPLAIN format per se
(which is really mooted by the changes
Ühel kenal päeval, K, 2010-02-10 kell 10:39, kirjutas Tom Lane:
Priit Laes pl...@plaes.org writes:
This patch enables showing configure status at the end of ./configure
run and thus makes ./configure process a bit easier to follow (in the
sense of what features are actually enabled).
I
On Wed, Feb 10, 2010 at 07:01:19PM +0200, Priit Laes wrote:
It might avoid the 'UU, I forgot to enable python support.',
after you have waited a while for the build to finish...
+1 from me, for that very reason!
Ross
--
Ross Reedstrom, Ph.D.
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
... It would be
really nice if we could get some feedback on the non-text formats
*before* they're set in stone.
Is Redhat's Visual Explain still alive? And what about Tom Raney's stuff?
Visual Explain is dead as far as
Hi Joachim,
On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland j...@mcknight.de
wrote:
http://www.postgresql.org/docs/8.4/static/backup-dump.html already
states about pg_dump: In particular, it must have read access to all
tables that you want to back up, so in practice you almost always have
On Wed, Feb 10, 2010 at 12:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
Markus Wanner wrote:
On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland j...@mcknight.de
wrote:
http://www.postgresql.org/docs/8.4/static/backup-dump.html already
states about pg_dump: In particular, it must have read access to all
tables that you want to back up, so in practice you almost
Perhaps you could supply a .sql file containing a testcase
illustrating the performance benefits you tested with your patch
Sure.
Attached the updated patch (should solve a bug) and a script.
The sql scripts generates a 2M rows table (orig); then the
table is copied and the copy clustered
So suppose at this point that step is the largest integer that can be
represented...
! step ++;
Boom.
! step= 1;
step= 1;
step ++'
Unboom?
!
! while(step 0) {
! int i;
! for (i = step-1; i nentry; i += 2 * step)
And similarly here... if
Teodor Sigaev escribió:
Also, rb_free is removed per Tom's comment. Can I commit the patch?
Hey, but rb_freefunc is still there ...
One very minor quibble: please make the $PostgreSQL$ lines be just that
(i.e. remove everything between the : to the terminating $, keeping the
latter)
--
2010/2/10 Teodor Sigaev teo...@sigaev.ru:
So suppose at this point that step is the largest integer that can be
represented...
! step ++;
Boom.
! step= 1;
step= 1;
step ++'
Unboom?
Yeah, that'll work.
!
! while(step 0) {
! int i;
!
On Wed, Feb 10, 2010 at 12:08 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
On Wed, Feb 10, 2010 at 11:58 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Is Redhat's Visual Explain still alive? And what about Tom Raney's stuff?
The core of Tom Raney's
On Wed, Feb 10, 2010 at 12:01 PM, Priit Laes pl...@plaes.org wrote:
Also, it's quite unclear which items deserve a place in the list.
If it's just to repeat what was in the configure command-line, what
is the value of that?
It might avoid the 'UU, I forgot to enable python support.',
I've been working on this
http://pgsql.privatepaste.com/2a81432f4f
for 8.3 (there should be some comments to port it to 8.4).
tsvector_tsquery_size works as expected.
But whatever I pass to the function I get an empty tsquery. Yet no
memory allocation problem or hang etc... just an empty
Robert Haas escribió:
On Wed, Feb 10, 2010 at 12:01 PM, Priit Laes pl...@plaes.org wrote:
Also, it's quite unclear which items deserve a place in the list.
If it's just to repeat what was in the configure command-line, what
is the value of that?
It might avoid the 'UU, I forgot
On Wed, Feb 10, 2010 at 2:16 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Maybe you didn't type it, but it came from elsewhere? Maybe you're
inheriting settings from some environment variable, or a file? Maybe
you're eval'ing pg_config --configure?
Yeah, could be.
The general idea
Hey, but rb_freefunc is still there ...
It will be reintroduced when ts_stat will be rewrited to use rbtree
One very minor quibble: please make the $PostgreSQL$ lines be just that
(i.e. remove everything between the : to the terminating $, keeping the
latter)
ok
--
Teodor Sigaev
I have a strange problem we noticed the other day with triggers. We're
running 8.3.3 on Solaris 10 (intel) and have a feed that comes in
regularly to populate a table we're working on. The feed works just
fine inserting rows however the following trigger stops the feed until
we remove the
On Wed, Feb 10, 2010 at 5:05 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-10 03:20 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-02-10 02:19 +0200, Tom Lane wrote:
You still haven't explained why it's a good idea to change the
On 2010-02-10 21:59 +0200, Robert Haas wrote:
On Wed, Feb 10, 2010 at 5:05 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-10 03:20 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-02-10 02:19 +0200, Tom Lane wrote:
You still haven't
Alvaro Herrera escreveu:
The general idea seems sensible to me. I can't comment on the
specifics.
+1. A lot of other programs have this summary at the end of configure
execution. The problem is that PostgreSQL has too many options. Do we want to
list all of them?
--
Euler Taveira de
Euler Taveira de Oliveira escribió:
Alvaro Herrera escreveu:
The general idea seems sensible to me. I can't comment on the
specifics.
+1. A lot of other programs have this summary at the end of configure
execution. The problem is that PostgreSQL has too many options. Do we want to
list
On Tue, Feb 09, 2010 at 09:34:10AM -0500, Andrew Chernow wrote:
Tollef Fog Heen wrote:
(please Cc me on replies, I am not subscribed)
Hi,
libpq currently does not use TCP keepalives. This is a problem in our
case where we have some clients waiting for notifies and then the
connection is
On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Euler Taveira de Oliveira escribió:
Alvaro Herrera escreveu:
The general idea seems sensible to me. I can't comment on the
specifics.
+1. A lot of other programs have this summary at the end of configure
Robert Haas robertmh...@gmail.com writes:
If the executor has buried in it the assumption that the snapshot
can't change after startup, then does that mean that we need to start
up and shut down the executor for each subquery?
Yes, I think so. That's the way it's always worked in the past;
On 2010-02-10 23:57 +0200, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
If the executor has buried in it the assumption that the snapshot
can't change after startup, then does that mean that we need to start
up and shut down the executor for each subquery?
Yes, I think so.
On 2/10/2010 7:12 AM, Tom Lane wrote:
Kurt, you seem to be more or less impervious to advice :-(.
Thank you for reviewing my patch. It is a rare honor to
have my personal qualities reviewed here as well.
Since this forum is archived for posterity, I suppose I
must point out that I have in
On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
On 2010-02-10 23:57 +0200, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
If the executor has buried in it the assumption that the snapshot
can't change after startup, then does that mean that we need to start
up and shut down the
Right now, log_error_verbosity displays the source code error location
in this format:
LOCATION: parserOpenTable, parse_relation.c:858
I think it would be clearer to add '()' next to the function name. We
use '() to display function names in our docs and I think using '()'
would
On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
On 2010-02-10 23:57 +0200, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
If the executor has buried in it the assumption that the snapshot
can't
On Jan 13, 2010, at 9:32 PM, Tom Lane wrote:
Jim Nasby deci...@decibel.org writes:
I noticed odd stuff showing up when I fired up an 8.3 psql after using psql
in HEAD. It shows up in .psql_history as well:
Platform? readline version?
This is on snow leopard. FWIW it's still doing it with
On 2010-02-11 01:58 +0200, Robert Haas wrote:
On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
Ok, what about the following:
- after planning the original query, standard_planner() goes through
the list
Takahiro Itagaki wrote:
Bruce Momjian br...@momjian.us wrote:
Where are we on this patch? We should at least implement the completion
for 'LANGUAGE' in 'DO', and use the existing pg_language query for
completion. I am attaching a patch that does exactly this.
I don't think we need
Bruce Momjian br...@momjian.us writes:
Right now, log_error_verbosity displays the source code error location
in this format:
LOCATION: parserOpenTable, parse_relation.c:858
I think it would be clearer to add '()' next to the function name. We
use '() to display function names in
Hello,
I noticed this morning that the k nearest neighbor gist patch
https://commitfest.postgresql.org/action/patch_view?id=230 was still being
considered for inclusion in 9. Sadly, this feature appears to have been
dropped from 9.
It seems to me that the functionality this brings is one of the
I hope people don't mind my asking about this on the list... as I hinted at
before, I don't really follow the development of PostgreSQL, I was just
interested in the Python driver project that I heard about.
Anyways, as I understand it, the current goal is to use psycopg and get it
changed to
On 2010-02-11 02:13 +0200, I wrote:
On 2010-02-11 01:58 +0200, Robert Haas wrote:
I have to admit I've been starting to have a feeling over the last
couple of days that this patch isn't going to make it for 9.0... but
obviously I'm in no position to guarantee anything one way or the
other.
u235sentinel u235senti...@gmail.com writes:
I have a strange problem we noticed the other day with triggers. We're
running 8.3.3 on Solaris 10 (intel) and have a feed that comes in
regularly to populate a table we're working on. The feed works just
fine inserting rows however the
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
If this doesn't fit in 24x80 maybe we need to find a more compact way to
display things.
+1. I wouldn't mind a one-line summary, but a two page summary seems
like a
On Monday 08 February 2010 05:53:23 Robert Haas wrote:
On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Andres Freund escribió:
I personally think the fsync on the directory should be added to the
stable branches - other opinions?
If wanted I can
Jim Nasby deci...@decibel.org writes:
On Jan 13, 2010, at 9:32 PM, Tom Lane wrote:
Jim Nasby deci...@decibel.org writes:
I noticed odd stuff showing up when I fired up an 8.3 psql after using psql
in HEAD. It shows up in .psql_history as well:
Platform? readline version?
This is on snow
On Wed, Feb 10, 2010 at 9:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
If this doesn't fit in 24x80 maybe we need to find a more compact way to
display things.
+1. I
Kris Jurka wrote:
The JDBC driver has two methods of disabling permanently planned prepared
statements:
1) Use the version two frontend/backend protocol via adding
protocolVersion=2 to your URL. This interpolates all parameters into
the query on the client side.
2) Execute
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen j...@xs4all.nl wrote:
Periodically re-plan prepared statements on EXECUTE. ?This is also a chance
for queries that were being re-planned every time to go back to a generic
plan.
Kevin Ar18 kevina...@hotmail.com writes:
When I first heard about the endeavor, I thought the goal was to take
one or several of the non-copyleft projects, which were rather
unfocused, and work with those teams to produce a really good
implementation for Python. However, as I understand it
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Right now, log_error_verbosity displays the source code error location
in this format:
LOCATION: parserOpenTable, parse_relation.c:858
I think it would be clearer to add '()' next to the function name. We
use '() to
Tom Lane escreveu:
I'm still quite dubious about the usefulness, but I could live with this
if someone explains to me how the printout is going to stay within 24x80
given the inevitable growth in number of configure options ...
AFAICS, we have 40 configure options. If we want this to fit in
Well, all else being equal we'd certainly prefer a library that was
licensed more like the core Postgres database. However, we don't have
infinite resources, and an LGPL license is not a showstopper (at least
not to the people who seem to be willing to work on this problem).
The
Bruce Momjian br...@momjian.us writes:
Can someone explain to me why we only do delayed binding for unnamed
prepared queries?
It was a way of shoehorning in some driver control over the behavior
without the protocol bump that would be involved in adding an actual
option to Parse messages.
Tom Lane wrote:
u235sentinel u235senti...@gmail.com writes:
I have a strange problem we noticed the other day with triggers. We're
running 8.3.3 on Solaris 10 (intel) and have a feed that comes in
regularly to populate a table we're working on. The feed works just
fine inserting rows
Kevin Ar18 wrote:
Based on that, I guess my question is what would it have taken to have
picked one of BSD/MIT projects and working with those people instead?
In other words, what key things affected the decision for psycopg?
What areas is it so far ahead in or that would have just been
u235sentinel escreveu:
I'm curious what context you were expecting and which group this should
go to. I've posted similar questions in the other groups and they
seem... lost at times.
What group? AFAICS this question belongs to -general. What about starting to
show us the definition of m_a,
That's just a matter of prioritizing the issues. Put the big ones at
the top, the trivia at the bottom, [...]
I'd like to see a requirement for the use of PQexecParams() over PQexec() -
even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy.
--
Andrew McNamara, Senior
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Feb 10, 2010 at 04:49:59PM -0800, Ragi Y. Burhum wrote:
Hello,
I noticed this morning that the k nearest neighbor gist patch
https://commitfest.postgresql.org/action/patch_view?id=230 was still being
considered for inclusion in 9. Sadly,
Andrew McNamara andr...@object-craft.com.au writes:
That's just a matter of prioritizing the issues. Put the big ones at
the top, the trivia at the bottom, [...]
I'd like to see a requirement for the use of PQexecParams() over PQexec() -
even when using libpq's PQescapeStringConn(),
Tom Lane wrote:
If you feel that a BSD/MIT license is a must-have for your purposes,
you're certainly free to push development of one of the other driver
projects instead, and to try to organize some other people to help.
I don't believe anyone is trying to funnel all development effort into
I'd like to see a requirement for the use of PQexecParams() over PQexec() -
even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy.
Such a rule seems pretty entirely pointless, unless you have a way to
enforce that the query string passed to the function hasn't been
assembled
This is very disgraceful from my point of view and reflects real problem
in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
reworked Nov 25. Long holidays in December-January, probably are reason why
there were no any movement on reviewing the patch. People with
inspiration
The only case that I think still has any merit is where you get a
significantly better plan with known parameter values than without.
The projected-cost threshold might be a reasonable approach for
attacking that, ie, if estimated cost of generic plan exceeds X
then take the time to build a
Oleg Bartunov o...@sai.msu.su writes:
This is very disgraceful from my point of view and reflects real problem
in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
reworked Nov 25. Long holidays in December-January, probably are reason why
there were no any movement on
1 - 100 of 102 matches
Mail list logo
