Python has an interface like this :
params = { 'mystrfield': 'hello', 'myintfield': 5 }
cursor.execute( "SELECT myfield FROM mytable WHERE
mystrfield=%(foo)s AND myintfield=%(bar)d;" , params )
It has the following advantages :
- separation of sql from data
- named parameters
Geoff Caplan wrote:
Hi folks
Seems we have two schools of thought:
1) The validation/escaping approach, supported by Bill and Jim
2) The "don't mix data with code" approach supported by Peter and
Greg.
As I learn more about the issues, I am increasingly veering towards
the second approach.
Now I a
Jim Seymour wrote:
Bill Moran <[EMAIL PROTECTED]> wrote:
[snip]
I agree with Bill. Years ago (more years than I care to recall) I read
a book on structured systems design (IIRC) that advised one should
condition/convert data as early as possible in the process, throughout
the design. Amongst the
I just updated the FAQ to suggest 32 as the header size (I am assuming
OID's and 4-byte alignment). I am also assuming 7.5 which will loose
the cmin/cmax compression.
---
Tom Lane wrote:
> Ian Barwick <[EMAIL PROTECTED]> wr
Igor Shevchenko <[EMAIL PROTECTED]> writes:
> I use binary mode for sending params and receiving data using libpq with
> protocol v3; PostgreSQL version is 7.4.3.
> Here, varchar[]-s are returned in binary mode; they're generated from internal
> structs by "array_send" function in src/backend/uti
Please confirm my request.
+++ Attachment: No Virus found
+++ Panda AntiVirus - www.pandasoftware.com
--- Trend GateLock [EMAIL PROTECTED] (主機：higp2.gatelock.com.tw)
** 中毒檔案 readme.doc
.pif 已刪除。
--
Ian Barwick <[EMAIL PROTECTED]> writes:
> There is a little info in the FAQ:
> http://www.postgresql.org/docs/faqs/FAQ.html
> particularly sections 4.6 and 4.14
I think the calculation in section 4.6 is out of date --- it's been
awhile since row headers were 36 bytes. The more correct number is
b
Steve Crawford <[EMAIL PROTECTED]> writes:
>>> I tracked down the process that was "idle in transaction" and it
>>> was a pg_dump process running on another machine.
>>
>> What was it waiting on?
> Beats the heck out of me. We periodically dump some selected small
> tables via a script using:
>
On Mon, 26 Jul 2004 18:14:06 -0400, David Parker
<[EMAIL PROTECTED]> wrote:
> Given a table, foo, created in a database but not populated, is there a
> procedure that will return an estimate of the size of a given tuple in
> that table? It looks like pgstattuple reports on actual table pages; I'm
>
Hi,
I use binary mode for sending params and receiving data using libpq with
protocol v3; PostgreSQL version is 7.4.3.
Here, varchar[]-s are returned in binary mode; they're generated from internal
structs by "array_send" function in src/backend/utils/adt/arrayfuncs.c.
PQftype(..) returns 1015
Given a table, foo, created in a database but not populated, is there a
procedure that will return an estimate of the size of a given tuple in
that table? It looks like pgstattuple reports on actual table pages; I'm
looking for something that reads the lengths of each row, and knows what
the storag
On Monday 26 July 2004 2:18 pm, Tom Lane wrote:
> Steve Crawford <[EMAIL PROTECTED]> writes:
> > A couple hundred processes were showing as "startup waiting" and
> > one was "idle in transaction". The process in the "VACUUM
> > waiting" state was the only one connected to that database - all
> > ot
Steve Crawford <[EMAIL PROTECTED]> writes:
> A couple hundred processes were showing as "startup waiting" and one
> was "idle in transaction". The process in the "VACUUM waiting" state
> was the only one connected to that database - all other connections
> were to other databases.
I suspect wha
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Steve Crawford
> Sent: Monday, July 26, 2004 1:23 PM
> To: [EMAIL PROTECTED]
> Subject: [GENERAL] vacuumdb hanging database cluster
>
>
> When I run:
> vacuumdb --full --all --analyze --quiet
> on
When I run:
vacuumdb --full --all --analyze --quiet
on my database cluster it will complete in < 2 minutes (this cluster
is a few million total rows and ~2GB).
After testing, I set this up as an off-hours cron job and it worked
fine for several days then hung the whole database. After my pager
On Mon, 2004-07-26 at 11:42, David Parker wrote:
> Hi. I understand from lurking on Hackers that 7.5 is nearing beta. What
> is the typical timeframe for a postgres beta? It's understood, of
> course, that beta might take longer depending on problems that show up,
> but I'm wondering if there is an
On Mon, 26 Jul 2004, Matthew T. O'Connor wrote:
David Parker wrote:
Hi. I understand from lurking on Hackers that 7.5 is nearing beta. What
is the typical timeframe for a postgres beta? It's understood, of
course, that beta might take longer depending on problems that show up,
but I'm wondering if
BiggerSQL is a cocoa based Postgresql Browser for Mac OS X.
Some of the features of this upgrade:
o Open Recent Menu activated.
o Macintosh Aliases are now recognized.
o A persistent history file is maintained.
o Column titles are centered and numeric data is right justified.
o This release has add
Magnus,
Your posting arrived just after I posted my attempt at a summary...
With the help of the list, I had already got to the stage that
parameterised queries are the way to go. Your post helps confirm
that.
Now I need to understand the implementation details. Clearly, one
option is the PREPAR
Hi folks
Seems we have two schools of thought:
1) The validation/escaping approach, supported by Bill and Jim
2) The "don't mix data with code" approach supported by Peter and
Greg.
As I learn more about the issues, I am increasingly veering towards
the second approach.
Obviously, proper valid
Tom Lane wrote:
> > I now find that sorting is very different with that setting: It
> > appears, through trial and error, that all non-alphanumeric
> > characters are completely ignored by ORDER BY.
>
> I doubt they are ignored completely, but they probably are ignored in
> the first-order comparis
> Most of the online literature is on MS SQL Server. There, the
> consensus seems to be that the range of potential attacks is
> so wide that attempting to spot attack signatures in posted
> data is a doomed enterprise, and that the safest general
> approach for any dynamically built query is t
22 matches
Mail list logo
