On Sun, May 01, 2005 at 11:19:16PM -0400, Tom Lane wrote:
> Vlad <[EMAIL PROTECTED]> writes:
> > i.e. the following perl code won't work correctly with DBD::Pg 1.40+
>
> > $dbh->do("SET search_path TO one");
> > my $sth1 = $dbh->prepare_cached("SELECT * FROM test WHERE item = ?");
> > $sth1->execu
Please reply to the same thread you start instead of starting a new one
every time (choose the last reply and hit "Reply to All").
[EMAIL PROTECTED] wrote:
I looked at the server machine, in a section regarding ip connections,
and saw that security was set to prevent other machines from connecti
Vlad <[EMAIL PROTECTED]> writes:
> so is it possible that a successfully prepared (and possibly a couple
> of times already executed) query will be invalidated by postgresql
> for some reason (like lack of memory for processing/caching other
> queries)? Assuming that no database structure changes
btw, after re-reading the second part of your comment once again, I
have a (clarification) question:
so is it possible that a successfully prepared (and possibly a couple
of times already executed) query will be invalidated by postgresql
for some reason (like lack of memory for processing/caching
yeah, I agree.
perhaps a more correct solution would be to adjust DBD::Pg to detect
changes of active schema and store instances of server side prepared
queries tieing them up with query + current schema, not only a query
as it's now (as I understand)...
On 5/2/05, Neil Conway <[EMAIL PROTECTED]
Neil Conway <[EMAIL PROTECTED]> writes:
> An alternative would be to flush dependent plans when the schema search
> path is changed.
I think this would actually be the Wrong Thing. It's certainly a
debatable point --- but the best analogy we have is the behavior of
plpgsql functions in the face
Tom Lane wrote:
That's what it is supposed to do. It would hardly be possible to
"prepare" a query at all if we had to wait till EXECUTE to find out
which tables it was supposed to use.
An alternative would be to flush dependent plans when the schema search
path is changed. In effect this would m
Vlad <[EMAIL PROTECTED]> writes:
> i.e. the following perl code won't work correctly with DBD::Pg 1.40+
> $dbh->do("SET search_path TO one");
> my $sth1 = $dbh->prepare_cached("SELECT * FROM test WHERE item = ?");
> $sth1->execute("one");
> $dbh->do("set search_path to two");
> my $sth2 = $dbh->p
Tom,
thanks for you reply.
> That's what it is supposed to do. It would hardly be possible to
> "prepare" a query at all if we had to wait till EXECUTE to find out
> which tables it was supposed to use.
I understand that from postgresql point of view everything is logical.
From the application
> the first problem you have is that you have a critical production system
> that you upgraded without going through proper test first.
> That's just bad change control.
> In any case, if the new DBD::Pg blew up in your face why did you not
> immediately revert to the previous working one? Even if
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> CSN <[EMAIL PROTECTED]> writes:
> > createlang: language installation failed: ERROR:
> > could not load library
> > "/usr/lib/postgresql/plperl.so": libperl.so:
> cannot
> > open shared object file: No such file or directory
>
> Notice it's complaining a
On Sun, 1 May 2005, Vlad wrote:
> Hello,
>
> I'm seeking for an advise to solve the issue that we hit recently
> (cost me sleepless night after production server upgrade).
the first problem you have is that you have a critical production system
that you upgraded without going through proper
CSN <[EMAIL PROTECTED]> writes:
> createlang: language installation failed: ERROR:
> could not load library
> "/usr/lib/postgresql/plperl.so": libperl.so: cannot
> open shared object file: No such file or directory
Notice it's complaining about libperl.so, not plperl.so.
This is probably because
Vlad <[EMAIL PROTECTED]> writes:
> SET search_path TO one;
> PREPARE st( VARCHAR(20) ) AS SELECT * FROM test WHERE item = $1;
> EXECUTE st( 'one' );
> SET search_path TO two;
> -- next statement fails because st selects from one.test, not from two.test
> EXECUTE st( 'two' );
That's what it is
On Sun, May 01, 2005 at 05:52:14PM -0700, CSN wrote:
> createlang: language installation failed: ERROR:
> could not load library
> "/usr/lib/postgresql/plperl.so": libperl.so: cannot
> open shared object file: No such file or directory
You need your Perl installation to have libperl as a shared
I had posted and emailed various places, to find a tutorial or example of
how to write my own scripts in Rekall to access Postgresql. Someone was
kind enough to send me the following example, so I want to share it with anyone
who may be interested in using Rekall as a front end to Postgresql
Hello,
I'm seeking for an advise to solve the issue that we hit recently
(cost me sleepless night after production server upgrade).
The actual environment is Apache+mod_perl, Postgresql 8.0.2. After
upgrading DBD::Pg to the 1.41 version (which supports preparing quries
on "server" side) we hit a
Harry Jackson <[EMAIL PROTECTED]> writes:
> The params are correct for the entry in the logs at [7-1] but if you
> look at [9-1] the params are in the wrong order. This looks odd to me
> and I was wondering if someone could explain this?
Not the same parameters --- those $n are plpgsql doing its o
I configured postgres base+opt with '--with-perl',
make'd, and make install'ed. Trying to add plperl:
createlang -U postgres plperl links
I get this error:
createlang: language installation failed: ERROR:
could not load library
"/usr/lib/postgresql/plperl.so": libperl.so: cannot
open shared obj
On Mon, 2 May 2005 06:05 am, CSN wrote:
> I'm following the directions here:
> http://plphp.commandprompt.com/documentation.html
>
> (Note that they differ from the directions included in
> plphp-7.4.x.tar.bz2, which I've also tried.)
>
> Using Postgres 7.4.7 and PHP 5.0.4. When I do this:
>
The
I have been trying to use PQexecPrepared but so far have been having
little success. I have looked at the docs and there is very little in
there by way of examples. I am not really a native C programmer hence
my reason for assuming its my own fault and not a bug in PG but I have
noticed some things
I'm following the directions here:
http://plphp.commandprompt.com/documentation.html
(Note that they differ from the directions included in
plphp-7.4.x.tar.bz2, which I've also tried.)
Using Postgres 7.4.7 and PHP 5.0.4. When I do this:
7. Build and install your plphp.so library.
cd src/pl
22 matches
Mail list logo
