Gaetano Mendola wrote:
Shachar Shemesh wrote:
Tom Lane wrote:
Parameters are only supported in plannable statements
(SELECT/INSERT/UPDATE/DELETE; I think there is some hack for DECLARE
CURSOR these days too).
That's a shame.
Aside from executing prepared statements, parameters are also useful
f
Bruce Momjian wrote:
> I get this failure on current CVS running configure --with-python:
>
> checking for python... /usr/local/bin/python
> checking for Python distutils module... no
> configure: error: distutils module not found
> gmake: *** [config.status] Error 1
What p
I get this failure on current CVS running configure --with-python:
checking for python... /usr/local/bin/python
checking for Python distutils module... no
configure: error: distutils module not found
gmake: *** [config.status] Error 1
I have python 1.5(1.5.
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2004-09-17 at 13:18, Tom Lane wrote:
>> In my mind this is just a clearer statement of what the policy always
>> was ;-). The patch review/application load was never supposed to fall
>> entirely on Bruce. The list he maintains is just there to ens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Another point is that since the ODBC driver is C anyway, there are no
> cross-language issues for it in relying on libpq. This is quite
> different IMHO from the situation for JDBC, or DBD::Pg, where there are
> advantages in having a single-lan
CC'ing pgsql-www, in the future please direct these kind of emails to that
group.
On Monday 20 September 2004 20:46, Gaetano Mendola wrote:
> Gaetano Mendola wrote:
> > Hi all,
> > I'm using the RSS on Mozilla Thundebird and I'm noticing that all
> > entries are with the date: 01/01/1970 othe
On Fri, 2004-09-17 at 13:18, Tom Lane wrote:
> In my mind this is just a clearer statement of what the policy always
> was ;-). The patch review/application load was never supposed to fall
> entirely on Bruce. The list he maintains is just there to ensure that
> nothing slips through the cracks.
On Fri, Sep 17, 2004 at 07:32:30PM -0400, Tom Lane wrote:
> involve consulting DNS? If so, try to correlate the crash probability
> with changes in your DNS zone contents ...
No changes. The systems in question have no access to DNS.
/etc/hosts only.
A
--
Andrew Sullivan | [EMAIL PROTECTED
Shachar Shemesh wrote:
Tom Lane wrote:
Parameters are only supported in plannable statements
(SELECT/INSERT/UPDATE/DELETE; I think there is some hack for DECLARE
CURSOR these days too).
That's a shame.
Aside from executing prepared statements, parameters are also useful for
preventing SQL injec
Gaetano Mendola wrote:
Hi all,
I'm using the RSS on Mozilla Thundebird and I'm noticing that all
entries are with the date: 01/01/1970 other sites are not affected
by this issue.
Of course I'm speaking about www.postgresql.org :-)
Watching at the two RSS:
http://www.postgresql.org/news.rss
http:
Laszlo Hornyak <[EMAIL PROTECTED]> writes:
> I have a error callback function registered to run each time an SQL
> error occurs. The problem is that the errfinish() calls it both if the
> executed SQL statement was wrong, and if the statem,ent or plan logging
> is enabled, and it seems elog.h do
What about the original request to turn off the bgwriter? Would setting
the delay to a very high value do that?
---
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> >>> bgwriter_delay = 50 (now default 200)
> >
Hi!
I have a error callback function registered to run each time an SQL
error occurs. The problem is that the errfinish() calls it both if the
executed SQL statement was wrong, and if the statem,ent or plan logging
is enabled, and it seems elog.h doesn't provide the API to find out the
reason w
Jan Wieck <[EMAIL PROTECTED]> writes:
>>> bgwriter_delay = 50 (now default 200)
>>> bgwriter_percent = 2(now default 1)
>>> bgwriter_maxpages = 200 (now default 100)
> Just what I was having the best TPC-C results with.
I'm a bit hesitant to reduce the default bgwriter_delay, since AFAICS
On 9/20/2004 2:02 AM, Michael Paesold wrote:
The bgwriter always flushes the oldest dirty buffers, and every buffer
touched (hit or faulted in). The output above doesn't tell you how many
buffers are really dirty. But if the system is under load, that is
pretty much the same as the distance between
Hi all,
I'm using the RSS on Mozilla Thundebird and I'm noticing that all
entries are with the date: 01/01/1970 other sites are not affected
by this issue.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 8: explain analyze is your friend
Joe Conway wrote:
Andre wrote:
Package variables are not transactional, additionaly they are
session based - each session has it's own variables(values).
You can assign initial(defult) values in package spec.
Using table for them would also imply several columns
for each datatype or several tables
Andre wrote:
Package variables are not transactional, additionaly they are
session based - each session has it's own variables(values).
You can assign initial(defult) values in package spec.
Using table for them would also imply several columns
for each datatype or several tables for them.
I did a
Hi there ,
i have this scenario :
- postgresql 7.5 ( with modified heap_* functions to retrieve data
from another dbms)
- the tuple's data is allocated in memory via palloc
(the tuple table slot and the heap tuple hold a pointer to the
data and not to the buffer pages nor hard
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Parameters are only supported in plannable statements
>> (SELECT/INSERT/UPDATE/DELETE; I think there is some hack for DECLARE
>> CURSOR these days too).
> That's a shame.
> Aside from executing prepared statements, parameters are al
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> At 2004-09-20 11:02:50 -0400, [EMAIL PROTECTED] wrote:
>> (2) What about discovering the actually resolved parameter types?
> Do you have any suggestions?
It depends on whether you think that PQprepare should bundle the
Describe Statement operation
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Oracle has package level variables which are not mappable to any postgres
equivalent.
could we have something like schema scope variables which could be
directly referred from let's say plpgsql functions?
Can someone give me some pointers on how to go abo
David Wheeler <[EMAIL PROTECTED]> writes:
> On Sep 20, 2004, at 12:34 AM, Bruce Momjian wrote:
>> I think we should favor libpq usage wherever possible and only
>> re-implement it in the native language when required, like for
>> jdbc/java.
> I don't normally post "me too" posts, but I think that
Tom Lane wrote:
Parameters are only supported in plannable statements
(SELECT/INSERT/UPDATE/DELETE; I think there is some hack for DECLARE
CURSOR these days too).
That's a shame.
Aside from executing prepared statements, parameters are also useful for
preventing SQL injections. Under those case
Sudhakar Kurumella wrote:
Hi,
I have recently downloaded, PostgreSql 8.0-beta2-dev3 windows version.
I am a newbie to postgresql, i have one question, How can i import or
export the existing postgresql database running under unix flavour to
windows based postgresql (8.0-beta2-dev3). Is there
Hi,
I have recently downloaded, PostgreSql 8.0-beta2-dev3 windows version. I am a newbie to postgresql, i have one question, How can i import or export the existing postgresql database running under unix flavour to windows based postgresql (8.0-beta2-dev3). Is there any facility under the new win
On Sep 20, 2004, at 12:34 AM, Bruce Momjian wrote:
I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for
jdbc/java.
I think having all interfaces take advantage of libpq improvements and
features is a major win. If we need to
At 2004-09-20 11:02:50 -0400, [EMAIL PROTECTED] wrote:
>
> (1) What about preparing an unnamed statement ...
stmtName == "" will work.
> (2) What about discovering the actually resolved parameter types?
I'm not sure what to do about that.
I could extend PGresult to hold ParameterDescription inf
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
>> PGresult *
>> PQprepare(PGconn *conn,
>> const char *stmtName,
>> const char *query,
>> int nParams,
>> const Oid *paramTypes);
> Should I go ahead and do that?
(1) What about preparing an unnamed statement .
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> create user $1 with encrypted password $2
> Any idea why this is not working?
Parameters are only supported in plannable statements
(SELECT/INSERT/UPDATE/DELETE; I think there is some hack for DECLARE
CURSOR these days too).
r
[EMAIL PROTECTED] writes:
> Oracle has package level variables which are not mappable to any postgres
> equivalent.
> could we have something like schema scope variables which could be
> directly referred from let's say plpgsql functions?
> Can someone give me some pointers on how to go about imp
At 2004-09-20 10:20:03 -0400, [EMAIL PROTECTED] wrote:
>
> What you should be concerned with right now is providing an API for
> Parse + Describe Statement, to substitute for the existing approach
> of setting up statement objects via PQexec("PREPARE foo ...").
Fair enough. That's why my original
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> Execute can be told to return no more than n rows of results. If there
> are more rows available, the server returns PortalSuspended and awaits
> another Execute message. The default of 0 imposes no limit.
> Because it's sometimes required to call Ex
Bruce Momjian wrote:
Interesting. So it times out a transaction to release its locks. Does
it time from the start of the transaction? I assume so. We do have
statment_timeout so maybe transaction_timeout would be the proper name.
Timing out on just the idle state seems strange to me.
Timing out
Interesting. So it times out a transaction to release its locks. Does
it time from the start of the transaction? I assume so. We do have
statment_timeout so maybe transaction_timeout would be the proper name.
Timing out on just the idle state seems strange to me.
-
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> (I apologise in advance if anyone receives multiple copies of this post.
> I posted from the wrong address earlier.)
>
> At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
> >
> > I assumed we would want a separate Bind and execute call. Do we?
Hi list,
When I try to create a user using the "create user" SQL command, where
the command is being executed using the PQexecParams function from
libpq, and the username and password are passed as "text" (oid 0x19)
parameters (binary), I get a syntax error. The command I'm doing is:
create use
sorry my last mail went incomplete
please read through this and ignore my last mail
paraM
- Forwarded by Paramveer Singh/Trilogy on 20/09/2004 05:21 PM -
Paramveer Singh
20/09/2004 05:56 PM
To: [EMAIL PROTECTED]
cc:
Subject: sch
hi!
I apologize for mailing on the hackers list but I posted on the general list and did not get a good answer.
I have two independent issues, but am addressing them together.
1.
Oracle has package level variables which are not mappable to any postgres equivalent.
could we have something like sch
Tom F said:
> Hi,
>
> I'm working on running postgresql in a chrooted filesystem.
>
> /src/backend/commands/dbcommands.c makes use of system(3): as far as I
> can see, this is only used to execute rm(1) and cp(1). I'd like to
> avoid placing /bin/sh in the root of the filesystem (which system()
> r
(I apologise in advance if anyone receives multiple copies of this post.
I posted from the wrong address earlier.)
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
>
> I assumed we would want a separate Bind and execute call. Do we?
Yes, we do. (See below.)
> Personally I find it annoying
> The only argument against it, that I'm aware of, is that
> system() is ANSI, while execve() is POSIX: i.e.
> portability... does windows have execve()? That could be done
> the way the current preprocessor conditionals yield rmdir
> instead of rm.
Windows does have execve(), though it's name
There was some previous discussion of whether DBD:pg should continue
using libpq or implement the wire protocol in Perl, and whether ODBC
should move to using libpq.
I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for jdbc/
43 matches
Mail list logo
