"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=cuckoo&dt=2005-11-15%2023:56:22
I took a closer look at this, and noticed something interesting:
ccache gcc -no-cpp-precomp -O2 -fno-strict-aliasing -g -Wall
-Wmissing-prototypes -Wmissing-declarations -b
On Wed, 16 Nov 2005, Robert Treat wrote:
On Tuesday 15 November 2005 04:03, Teodor Sigaev wrote:
Look at HEAD branch.
Kaare Rasmussen wrote:
David Fetter writes in PostgreSQL Weekly News - November 13 2005:
Teodor Sigaev has been making lots of improvements to tsearch2, a
full-text search en
Philip Yarra <[EMAIL PROTECTED]> writes:
> This is because lost+found exists. Since lost+found would be a reasonably
> common directory to find at a mount-point on Unix-like OSs*, would it make
> sense for CREATE TABLESPACE to ignore it if present?
No. There is no reason to use a volume's root
On Thu, 17 Nov 2005, Philip Yarra wrote:
> I assume CREATE TABLESPACE refuses to use a non-empty directory because of the
> risk of trashing existing files. Makes sense, but consider the following:
Right, that was the reasoning.
>
> # mkfs -t ext2 /dev/sdc1
> # mount -t ext2 /dev/sdc1 /mnt/pg_ta
I assume CREATE TABLESPACE refuses to use a non-empty directory because of the
risk of trashing existing files. Makes sense, but consider the following:
# mkfs -t ext2 /dev/sdc1
# mount -t ext2 /dev/sdc1 /mnt/pg_tables
# chown postgres /mnt/pg_tables
# su -c psql pyarra
pyarra=# CREATE TABLESPACE
Hi guys,
I've set up a new sample databases project:
http://pgfoundry.org/projects/dbsamples/
If any of you have sample databases (schema + data, pg_dump format) that
you are willing to share under the BSD license, please send 'em to me so
I can host them on the project.
You might also find
On Tuesday 15 November 2005 04:03, Teodor Sigaev wrote:
> Look at HEAD branch.
>
> Kaare Rasmussen wrote:
> > David Fetter writes in PostgreSQL Weekly News - November 13 2005:
> >> Teodor Sigaev has been making lots of improvements to tsearch2, a
> >> full-text search engine.
> >
> > I can't find t
On Wednesday 16 November 2005 21:05, Alvaro Herrera wrote:
> Christopher Kings-Lynne wrote:
> > >I've never been a fan of "regression tests" in the narrow sense of
> > >"let's test for this specific mistake we made once". If you can devise
> > >a test that catches a class of errors including the o
Christopher Kings-Lynne wrote:
> >I've never been a fan of "regression tests" in the narrow sense of
> >"let's test for this specific mistake we made once". If you can devise
> >a test that catches a class of errors including the one you actually
> >made, that's a different story, because it's muc
I've never been a fan of "regression tests" in the narrow sense of
"let's test for this specific mistake we made once". If you can devise
a test that catches a class of errors including the one you actually
made, that's a different story, because it's much more likely to catch a
real future probl
Greg Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
Joe Conway <[EMAIL PROTECTED]> writes:
First, the spec only allows arrays to have a lower bound of 1. That
requirement simplifies a whole lot of things. I don't think that many
people actually depend on other than 1 as a lower bound (or at
Apparently the machine hung in between those two times.
I don't have any specific information, I am debugging remotely over
the phone.
Dave
On 16-Nov-05, at 5:21 PM, Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
Nov 16 18:03:32 dx1-ptr postgres[23410]: [4-1] LOG: shutting down
Tom Lane <[EMAIL PROTECTED]> writes:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > First, the spec only allows arrays to have a lower bound of 1. That
> > requirement simplifies a whole lot of things. I don't think that many
> > people actually depend on other than 1 as a lower bound (or at leas
Yann Michel wrote:
> ... I guiess that the AUTOVACUUM switch only does an automated VACUUM
> but no VACUUM FULL?
Certainly.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)
On Wed, Nov 16, 2005 at 04:51:07PM -0500, Tom Lane wrote:
> daveg <[EMAIL PROTECTED]> writes:
> > I agree, but would like to relax the primary key requirement to simply
> > a unique index. I can see use cases for unique so long as not null keys,
> > so it would be nice if the MERGE operation would
Dave Cramer <[EMAIL PROTECTED]> writes:
> Nov 16 18:03:32 dx1-ptr postgres[23410]: [4-1] LOG: shutting down
> Nov 16 18:03:35 dx1-ptr postgres[23410]: [5-1] LOG: database system
> is shut down
> Nov 16 18:21:18 dx1-ptr postgres[10884]: [1-1] LOG: could not create
> IPv6 socket: Address famil
Joe Conway <[EMAIL PROTECTED]> writes:
> First, the spec only allows arrays to have a lower bound of 1. That
> requirement simplifies a whole lot of things. I don't think that many
> people actually depend on other than 1 as a lower bound (or at least if
> they do, they weren't dumping and reloa
Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Tom Lane <[EMAIL PROTECTED]> writes:
Well, in that case what do you think about
{{1,2},{3,4},{5,6},{7,8}}
vs
{{1,2,3,4},{5,6,7,8}}
In the first case the first element is {1,2} and in the second case the first
element is {1,2,3,4} so fro
daveg <[EMAIL PROTECTED]> writes:
> I agree, but would like to relax the primary key requirement to simply
> a unique index. I can see use cases for unique so long as not null keys,
> so it would be nice if the MERGE operation would work for these. As nulls
> are not "equal" anyway this doesn't see
On Wed, Nov 16, 2005 at 09:49:28AM -0500, Tom Lane wrote:
> I think we should do REPLACE-like functionality that simply fails if the
> match condition isn't equality on a primary key. If we can use SQL-spec
> MERGE syntax for this, that's fine, but let's not think in terms of
> silently changing t
Conceptually, a MERGE statement is just a long string of INSERTs and
UPDATEs in the same transaction and I think we should treat it as
such.
I've just got one question about this. Everyone seems to be saying
that "try to insert and if that fails update" is the same as "try to
insert and i
Other than backing up $PGDATA
and running pg_resetxlog
Is there any advice ?
Dave
Nov 16 18:03:30 dx1-ptr postgres[22337]: [6-2] '2005-11-16 17:47:31'
Nov 16 18:03:32 dx1-ptr postgres[29335]: [2-1] LOG: received fast
shutdown request
Nov 16 18:03:32 dx1-ptr postgres[29335]: [3-1] LOG: abor
David Fetter <[EMAIL PROTECTED]> writes:
> On Wed, Nov 16, 2005 at 03:03:53PM -0500, Greg Stark wrote:
>> It occurs to me that it would also make sense to have an operator
>> that considered the arrays in an order-insensitive comparison.
> That sounds more like the SQL:2003 MULTISET, which is ess
On Wed, Nov 16, 2005 at 03:03:53PM -0500, Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > I could go for a separate operator that has the current behavior
> > (might as well ignore number of dimensions too, if we're going to
> > ignore bounds). Any thoughts about the operator na
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Well, in that case what do you think about
>> {{1,2},{3,4},{5,6},{7,8}}
>> vs
>> {{1,2,3,4},{5,6,7,8}}
> In the first case the first element is {1,2} and in the second case the first
> element is {1,2,3,4} so from my
Tom Lane <[EMAIL PROTECTED]> writes:
> Well, in that case what do you think about
> {{1,2},{3,4},{5,6},{7,8}}
> vs
> {{1,2,3,4},{5,6,7,8}}
In the first case the first element is {1,2} and in the second case the first
element is {1,2,3,4} so from my point of view there's no way these a
Hi,
On Wed, Nov 16, 2005 at 10:07:24AM -0500, Tom Lane wrote:
> Yann Michel <[EMAIL PROTECTED]> writes:
> > Well, now that I'm thinking about, what you've written I think this is
> > exactly the point. I think, that there is a VACUUM waiting for the dump
> > to finish whereas the INSERTS are waiti
Hi Martijn,
On Wed, Nov 16, 2005 at 09:47:33AM +0100, Martijn van Oosterhout wrote:
>
> Ah yes, PostgreSQL doesn't use 2PL, it uses MVCC. quick overview here:
> http://linuxgazette.net/issue68/mitchell.html
THX! That was interesting!
> > Thanks. BTW: Is there anything about locks and their mean
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I could go for a separate operator that has the current behavior
>> (might as well ignore number of dimensions too, if we're going to
>> ignore bounds). Any thoughts about the operator name?
> Well to me these are tw
On Tue, Nov 15, 2005 at 13:01:20 -0500,
Dave Cramer <[EMAIL PROTECTED]> wrote:
> I've talked to Ken Geis via email. He suggests that there is
> considerable overhead to be saved if we go to binary; especially in
> date, and timestamp fields
>
> One thing though if the date is 64 bit instead
Tom Lane <[EMAIL PROTECTED]> writes:
> I could go for a separate operator that has the current behavior
> (might as well ignore number of dimensions too, if we're going to
> ignore bounds). Any thoughts about the operator name?
Well to me these are two different cases. At least the way I see it
Greg Stark <[EMAIL PROTECTED]> writes:
> And changing that would make it harder to test just the contents of the array
> without having to match bounds as well.
Fair point, but currently it's impossible to make a comparison that
*does* consider the bounds, which one would think would be the ordina
On Wed, Nov 16, 2005 at 11:06:15AM -0800, Dann Corbit wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> > [EMAIL PROTECTED] On Behalf Of Simon Riggs
> > > Conceptually, a MERGE statement is just a long string of INSERTs and
> > > UPDATEs in the same transact
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Simon Riggs
> Sent: Wednesday, November 16, 2005 10:35 AM
> To: Martijn van Oosterhout
> Cc: Bruce Momjian; Rick Gigger; Tom Lane; Christopher Kings-Lynne; Jim
C.
> Nasby; josh@agliodbs.co
Tom Lane <[EMAIL PROTECTED]> writes:
> regression=# select '[0:2]={1,2,3}'::int[] = '{1,2,3}'::int[];
> ?column?
> --
> t
> (1 row)
>
> regression=# select '{1,2,3,4}'::int[] = '{{1,2},{3,4}}'::int[];
> ?column?
> --
> t
> (1 row)
>
> This seems pretty bogus as well.
The
On Wed, Nov 16, 2005 at 12:59:36PM -0500, Bruce Momjian wrote:
> Martijn van Oosterhout wrote:
> > The bit I'm still missing is why there needs to be a lock at all. The
> > SQL standard doesn't say anywhere that concurrent MERGE operations
> > can't conflict. It seems to me that standard visibility
On Wed, 2005-11-16 at 18:34 +0100, Martijn van Oosterhout wrote:
> On Wed, Nov 16, 2005 at 11:37:46AM -0500, Bruce Momjian wrote:
> >
> > Interesting approach. Actually, we could tell the user they have to use
> > BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
> > already have
On Wed, 2005-11-16 at 13:09 -0500, Bruce Momjian wrote:
> I leaving for Mexico in a few hours to speak at a conference. I return
> on Monday.
>
> Is it helpful to tell hackers when I am not around? I was in NYC last
> week for four days and didn't publicize it. Of course, I didn't finish
> my b
I leaving for Mexico in a few hours to speak at a conference. I return
on Monday.
Is it helpful to tell hackers when I am not around? I was in NYC last
week for four days and didn't publicize it. Of course, I didn't finish
my backlog of email until yesterday. I guess the question is whether my
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I wonder if there should be regression tests for all the bugs exposed
> after 8.1 ... I mean, what stops anyone from introducing the same bugs
> again?
I've never been a fan of "regression tests" in the narrow sense of
"let's test for this specific mist
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Wed, Nov 16, 2005 at 11:37:46AM -0500, Bruce Momjian wrote:
> >
> > Interesting approach. Actually, we could tell the user they have to use
> > BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
> > already have a t
Tom Lane wrote:
> Log Message:
> ---
> make_restrictinfo() failed to attach the specified required_relids to
> its result when the clause was an OR clause. Brain fade exposed by
> example from Sebastian B?ck.
I wonder if there should be regression tests for all the bugs exposed
after 8.1
While hacking on the nulls-in-arrays addition, I noticed a couple of
behaviors that seem a bit bogus to me.
First, array slicing returns NULL any time the requested slice falls
completely outside the array bounds. For instance
regression=# select ('{1,2,3}'::int[])[2:4];
int4
---
{2,3}
(1
On Wed, Nov 16, 2005 at 11:37:46AM -0500, Bruce Momjian wrote:
>
> Interesting approach. Actually, we could tell the user they have to use
> BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
> already have a table lock.
The bit I'm still missing is why there needs to be a lock at
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED]:13]~/buildfarm/source:39%otool -L `which perl`
> /opt/local/bin/perl:
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 71.1.3)
These aren't particularly relevant: you need to look at the shared
libr
On Wed, Nov 16, 2005 at 11:50:51AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > I do have perl, python, tcl and nls enabled, could one of them
> > be trying to pull libssl and libcrypto in for some reason?
>
> Perhaps --- try "otool -L" (local equivalent of ldd) on them
Jaime Casanova wrote:
> On 11/16/05, Bruce Momjian wrote:
> >
> > Interesting approach. Actually, we could tell the user they have to use
> > BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
> > already have a table lock.
> >
>
> If the lock will be required, what's the problem
Jaime Casanova <[EMAIL PROTECTED]> writes:
> If the lock will be required, what's the problem in doing it
> internally?
I already explained that: lock upgrading is deadlock-prone.
regards, tom lane
---(end of broadcast)---
T
On 11/16/05, Bruce Momjian wrote:
>
> Interesting approach. Actually, we could tell the user they have to use
> BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
> already have a table lock.
>
If the lock will be required, what's the problem in doing it
internally? without user i
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> I do have perl, python, tcl and nls enabled, could one of them
> be trying to pull libssl and libcrypto in for some reason?
Perhaps --- try "otool -L" (local equivalent of ldd) on them to find
out.
regards, tom lane
---
Yes, sorry for the mess. The problem was somewhere else (not quite
well written log procedure issuing conversion used for logging, even
tho log was off).
--
GJ
"If we knew what we were doing, it wouldn't be called Research, would
it?" - AE
---(end of broadcas
Interesting approach. Actually, we could tell the user they have to use
BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
already have a table lock.
---
Rick Gigger wrote:
> I agree. I would never ever ever
> You could also just add something to the merge syntax like ALLOW
> TABLE LOCK or something. The idea is just that the user can
> explicitly allow the table lock and thus the more complicated merge.
>
The problem here is that many people will see that option and think
it's safe to do it... i mea
On Tue, Nov 15, 2005 at 10:27:06PM -0600, Jim C. Nasby wrote:
> On Tue, Nov 15, 2005 at 11:04:59PM -0500, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > So the recent thread about getting 7.4 compiling on OS X inspired me.
> > > But what I can't understand is that I've yanked
I agree. I would never ever ever want it to silently start doing
table locks. I would simply avoid using merge at all if that was a
possibility.
However it seems like the idea is to eventually flesh out full
fledged merge. And to do that it sounds like you would need to do
one of the f
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for l
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>>> So the recent thread about getting 7.4 compiling on OS X inspired me.
>>> But what I can't understand is that I've yanked --with-ssl, but it's
>>> still looking for libssl:
>> Tad hard to
Grzegorz Jaskiewicz <[EMAIL PROTECTED]> writes:
> I have few fprintf(stderr,""") in function that converts internal
> rep. into string. I was really supprised to see them on me screen when :
> select count(b) from blah where b ~ 'something';
> was issued. What the hell, isn't it wrong ?
Depends
Yann Michel <[EMAIL PROTECTED]> writes:
> Well, now that I'm thinking about, what you've written I think this is
> exactly the point. I think, that there is a VACUUM waiting for the dump
> to finish whereas the INSERTS are waiting for the VACUUM to finish.
Only if it's a VACUUM FULL ... plain VACU
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:
Tad hard to believe. Maybe you missed a "make distclean" o
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> We should probably throw a notice or warning if we go to a table lock,
>> too.
> That's not very useful, because you can only do somethign about it AFTER
> the 1 hour exclusive lock merge has already run :)
We shouldn't do anything remotely
> I'm asking, because we have a bigger datawarehouse and dump the data for
> a backup every night. Unfortunately, the backup now takes realy long.
You may want to consider upgrading and using PITR backups instead. They
can be much faster to both backup and to restore if something goes
wrong.
--
Pollard, Mike schrieb:
If count() convert to a string (an assumption that Martijn
has cast into doubt, or perhaps shredded), then rather than convert all
non-nulls that are not a string into a string, I was proposing
converting the values into an int with the values 0 or 1 (0 means that
row was
Martijn van Oosterhout writes:
> Unless you use something like pgpool, in which case a single session
> may include multiple requests.
Actually, I've found pgpool to be no better when it comes to using
real prepared queries---there's no guarantee that any given request is
going to connect to the
If count() convert to a string (an assumption that Martijn
has cast into doubt, or perhaps shredded), then rather than convert all
non-nulls that are not a string into a string, I was proposing
converting the values into an int with the values 0 or 1 (0 means that
row was null for that column, 1
On Wed, Nov 16, 2005 at 08:28:28AM -0500, Pollard, Mike wrote:
> Details, details. But there is a valid general question here, and
> changing the semantics of the query will not address it. When doing a
> count(col), why convert col into a string just so you can determine if
> it is null or not?
Pollard, Mike schrieb:
Richard Huxton wrote:
Pollard, Mike wrote:
Firstly, if you just want a count, what's wrong with count(1) or
count(*).
Because unless the column does not allow nulls, they will not return
the
same value.
Ah, but in the example given the column was being matched
Richard Huxton wrote:
> Pollard, Mike wrote:
> >>Firstly, if you just want a count, what's wrong with count(1) or
> >>count(*).
> >>
> >
> >
> > Because unless the column does not allow nulls, they will not return
the
> > same value.
>
> Ah, but in the example given the column was being matched ag
Pollard, Mike wrote:
Firstly, if you just want a count, what's wrong with count(1) or
count(*).
Because unless the column does not allow nulls, they will not return the
same value.
Ah, but in the example given the column was being matched against a
value, so nulls were already excluded.
> Firstly, if you just want a count, what's wrong with count(1) or
> count(*).
>
Because unless the column does not allow nulls, they will not return the
same value.
Mike Pollard
SUPRA Server SQL Engineering and Support
Cincom Systems, Inc.
Better to remain silen
On K, 2005-11-16 at 10:05 +0100, Grzegorz Jaskiewicz wrote:
> Hi folks
>
> We're developing here gist index (which works finally, and I remember
> about writing some docs about it).
> I have few fprintf(stderr,""") in function that converts internal
> rep. into string. I was really supprised t
On Wed, Nov 16, 2005 at 10:05:36AM +0100, Grzegorz Jaskiewicz wrote:
> Hi folks
>
> We're developing here gist index (which works finally, and I remember
> about writing some docs about it).
> I have few fprintf(stderr,""") in function that converts internal
> rep. into string. I was really su
Mario Weilguni wrote:
> Ok, this my fault, and you're right.
>
> I took the query from the error messages (a 8.0.3 DB) and applied it to a 8.1
> DB on a testing system without thinking too much.
>
> Still I think reordering those queries might prevent a deadlock.
Well, if we could reorder them,
Hi folks
We're developing here gist index (which works finally, and I remember
about writing some docs about it).
I have few fprintf(stderr,""") in function that converts internal
rep. into string. I was really supprised to see them on me screen when :
select count(b) from blah where b ~ 'so
Ok, this my fault, and you're right.
I took the query from the error messages (a 8.0.3 DB) and applied it to a 8.1
DB on a testing system without thinking too much.
Still I think reordering those queries might prevent a deadlock.
Best regards
Am Mittwoch, 16. November 2005 12:21 schrieb Alvaro
Mario Weilguni wrote:
Hi,
> T1: BEGIN;
> T2: BEGIN;
> -- these are the queries similar to those from the foreign key code
> T1: SELECT 1 FROM ONLY lookup1 x WHERE "id" = 1 FOR UPDATE OF x;
> T2: SELECT 1 FROM ONLY lookup2 x WHERE "id" = 3 FOR UPDATE OF x;
> T1: SELECT 1 FROM ONLY lookup2 x WHERE
Peter Eisentraut wrote:
> Am Dienstag, 15. November 2005 00:01 schrieb Alvaro Herrera:
> > Good question. Peter, is pgtranslation supposed to be the primary
> > source of translations?
>
> Yes, and more importantly, your changes will get overwritten by pgtranslation.
Ok, I'll update it too and m
I've a problem occurring daily for me, I get quite a few deadlocks every day,
and the concurrency is not so high. Happens with postgresql 8.0 and 8.1. as
well...
Here's a self-contained testcase, which I think it might be the problem I have
in our production database. While it might be some sor
On Nov 16, 2005, at 15:37 , Michael Glaesemann wrote:
I'm using per-branch configurations, but missed HEAD. I'll get that
fixed. Thanks for the catch.
Back to normal:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=wallaroo&dt=2005-11-16%
2009:12:09
Michael Glaesemann
grzm myrealbox com
Martijn van Oosterhout wrote:
But this is of no use in a web-context. According to the docs, this
prepare is per session.
Unless you use something like pgpool, in which case a single session
may include multiple requests.
ok. Good point.
This sql cache I think is a really good thing. Is the
Christopher Kings-Lynne wrote:
> Oracle recently gave some money to Zend to make proper Oracle
support
> for PHP. In that interface they use bind variables. Apart from
greater
> speed, sqlinjection becomes history as well.
I did the same for PostgreSQL for PHP 5.1.
http://
On Wed, Nov 16, 2005 at 09:56:44AM +0100, Marcus Engene wrote:
> Douglas McNaught wrote:
> >You can do this (or close to it) but you need to explicitly PREPARE
> >the query (or use the protocol-level prepare, which some client
> >libraries will do for you). See the SQL documentation for PREPARE.
>
Douglas McNaught wrote:
Which will be the same as the second call. There is quite a big
difference in performance using bind variables.
Does Postgres work the same? Where can I go for more info?
You can do this (or close to it) but you need to explicitly PREPARE
the query (or use the protocol-
On Wed, Nov 16, 2005 at 09:27:55AM +0100, Yann Michel wrote:
> On Wed, Nov 16, 2005 at 08:28:31AM +0100, Martijn van Oosterhout wrote:
> > On Wed, Nov 16, 2005 at 08:09:31AM +0100, Yann Michel wrote:
> > > Well, thanks for all the answers. Are the locks then released once they
> > > are not needed
Am Dienstag, 15. November 2005 00:01 schrieb Alvaro Herrera:
> Good question. Peter, is pgtranslation supposed to be the primary
> source of translations?
Yes, and more importantly, your changes will get overwritten by pgtranslation.
---(end of broadcast)-
Hi,
first of all, thanks to all, that replied!
On Wed, Nov 16, 2005 at 08:28:31AM +0100, Martijn van Oosterhout wrote:
> On Wed, Nov 16, 2005 at 08:09:31AM +0100, Yann Michel wrote:
> > Well, thanks for all the answers. Are the locks then released once they
> > are not needed any more like in 2PC
86 matches
Mail list logo
