[GENERAL] This is my first template

2009-04-21 Thread Geoff Caplan

Hi folks

Looks like there's something I'm not understanding about 
date/time queries on a date field.


I have a param query that includes the statement:

AND active_from_date <= $2

where $2 is a well-formed ISO date.

Query works as expected when there are records in the result 
set. When the result set is empty, PG throws an error:


date/time field value out of range: "2011-4-31"

I'm using the default datestyle setting, which should work 
here, I think? Experimenting with other settings hasn't helped.


This query runs hundreds of times a day and I don't want the 
error clogging up my logs. But I don't want to suppress the 
error as the query is business-critical and I need to know 
if anything goes wrong.


I'd welcome suggestions as to how I can get this query to 
run without throwing a date/time error when the result set 
is empty.


Thanks...

--
Geoff Caplan
Uviva Ltd

begin:vcard
fn:Geoff Caplan
n:Caplan;Geoff
org:Uviva Ltd
adr:Dartington Hall;;Foxhole;Totnes;Devon;TQ9 6EB;UK
email;internet:ge...@uviva.com
tel;work:01803 840 840
x-mozilla-html:FALSE
url:http://www.uviva.com
version:2.1
end:vcard


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] Stuck with a query...

2005-03-08 Thread Geoff Caplan
Greg,

GS> There's no efficient way to write this in standard SQL.
GS> However Postgres has an extension DISTINCT ON that would
GS> do it:

Works as advertised - many thanks! I'd missed the DISTINCT
ON extension...

This really is a great list - you've saved me a couple of
hours of agony, I suspect.

------ 
Geoff Caplan
Vario Software Ltd
(+44) 121-515 1154 


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


[GENERAL] Stuck with a query...

2005-03-08 Thread Geoff Caplan
Hi folks,

Sorry to ask a newbie SQL question but I'm struggling...

I have a website clickstream log:

request_id   session_id  sequence_num  url
100  xxx 1 /foo
101  xxx 2 /bar
102  xxx 3 /hoo
103  yyy 1 /foo
104  yyy 2 /bar

I need to count the number of times each url was an exit
page. An exit page is the highest sequence_num for each
session_id - 102 & 104 in the example. The report would look
like:

Exit pages:

/foo 4555
/bar 3204
/hoo 2337

etc...

Any pointers would be much appreciated!

------ 
Geoff Caplan
Vario Software Ltd
(+44) 121-515 1154 


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [GENERAL] Performance critical technical key

2004-08-12 Thread Geoff Caplan
Bruno Wolff III wrote:

>>> Using a sequence shouldn't be slow.

Thanks - that's the main thing I need to know.

>>> The main potential problem is that it will make the session IDs
>>> guessible if you don't take any other steps. That may or may not
>>> be a problem.

Thanks for the warning, but I won't be using the sequence number as
the session id: as you say, not a safe thing to do. The session record
key persists from session to session: it is used to link sessions with
browsers and with user accounts. The session key will be a random 32
character key generated for each session.

Christopher Browne wrote:

>>> Why, in particular, would you expect the sequence to slow down
>>> inserts?  They don't lock the table.

I was assuming that generating the sequence number was expensive: it
is some other DBs I have used. That was why I was thinking of
providing a unique id via a random string. But a practical test shows
that in PG it is pretty fast, so there is not need.

>>> Note that if you're really doing a lot of INSERTs in parallel, you
>>> might find it worthwhile to configure the sequence to cache some
>>> number of entries so that they are pre-allocated and stored in memory
>>> for each session (e.g. - for each connection) for quicker access.  See
>>> the documentation for "create sequence" for more details...

I think that would be worthwhile.

Thanks for the input, folks.

-- 
Geoff Caplan
Vario Software Ltd
(+44) 121-515 1154 


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


[GENERAL] Performance critical technical key

2004-08-12 Thread Geoff Caplan
Hi folks

I'm designing a table to be used for web session management. If all
goes well with the project, the table should have 100,000+ records and
be getting hammered with SELECTS, INSERTS and UPDATES.

The table will need a technical key. The question is, what is the most
efficient way to do this?

a) Generate a random 24 character string in the application. Very
quick for the INSERTs, but will the longer key slow down the the
SELECTs and UPDATES?

b) Use a sequence. Faster for the SELECTS and UPDATES, I guess, but
how much will the sequence slow down the INSERTS on a medium sized
record-set?

There will probably be 6-8 SELECTs & UPDATEs for each INSERT.

I appreciate that I could set up some tests, but I am under the hammer
time-wise. Some rule-of-thumb advice from the list would be most
welcome.

------ 
Geoff Caplan
Vario Software Ltd
(+44) 121-515 1154 


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [GENERAL] Correct escaping of untrusted data

2004-08-05 Thread Geoff Caplan
Tom,

Belated thanks for the info (I've been away from my desk).

Very helpful.

------ 
Geoff Caplan
Vario Software Ltd
(+44) 121-515 1154 


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [GENERAL] Sql injection attacks

2004-07-28 Thread Geoff Caplan
Hi folks

Very instructive thread. Thanks to everyone for the input, and
especial thanks to Lincoln Yeoh for his detailed explanation of his
approach: a standout post!

Sorry for the silence - it's not that I'm unappreciative, just that
I've been away from my desk.

Tom Lane wrote:

> I think you misunderstood.  Escaping is perfectly safe (given a correct
> escaping function) if it's used on *every* untrustworthy input string.
> The argument for the "keep data separate from code" approach is
> essentially just that it's easier to be sure you haven't forgotten
> anyplace where you need to escape.

You are right: I was misunderstanding the nature of the problem. I now
appreciate that any effective approach must include both validation
and escaping of all untrusted data used in a query, both when it is
first passed into the application, and also when it is re-used from
the data store.

But I'd like to be sure I understand exactly what Tom means by "a
correct escaping function"? What are the potential breakout strings
you have to check for, and are they all caught by the standard
Postgres API escaping functions in PHP, Tcl etc?

For example, with SQL Server, it appears you can slip in a
single-quote using encodings that are cast to ASCII #39 by the server.
Also, what about pg functions like convert()? Could they be used to
smuggle in a breakout character?

Looked at like this, perhaps robust escaping is not so simple? Any
advice much appreciated.

-- 
Geoff Caplan
Vario Software Ltd
(+44) 121-515 1154 


---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [GENERAL] Sql injection attacks

2004-07-26 Thread Geoff Caplan
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 PREPARE/EXECUTE statements. But I am not sure I follow
you when you say:

MH> If you use the parametrised formats, e.g.
MH> "SELECT * FROM foo WHERE [EMAIL PROTECTED]"
MH> or just "sp_foo" in the case of the stored procedure (the driver will
MH> pick up parameter names automatically)

Are you saying that "@bar" is part of the Postgres query syntax? If it
is, I can't find it in the 7.4 docs. What do you mean by "the
parameterised formats"? I would appreciate a clarification and the URL
of the relevant documentation.

Thanks

-- 
Geoff Caplan
Vario Software Ltd
(+44) 121-515 1154 


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [GENERAL] Sql injection attacks

2004-07-26 Thread Geoff Caplan
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 validation is a given for all kinds of reasons. But
the problem with validation/escaping as the primary defense against
injection seems to be that simply escaping would not catch every type
of insertion via strings.

If you are just saving the untrusted string as a value, then the
attacker needs to use a quote or comment to escape out of the value
and alter the query syntax. This is relatively easy to counter, as
Bill suggests.

But in web work, you are often using GET/POST data directly in your
SQL clauses, so the untrusted data is part of the query syntax and not
just a value.

In that scenario, if you just concatenate your untrusted data into
your query, it is relatively easy for the attacker to sneak in
AND/OR/UNION type clauses without using quotes. This means that you
have to check strings for attack signatures as well, which is not
trivial if you are going to avoid false positives. And it means that
every single untrusted string has to be screened by someone skilled at
analysing the potential threats and writing the right Regexes. And as
Greg point out, you only have to screw up once and you have opened up
your whole system. Plus, as new attacks are developed, you have to
audit all your code to counter them. This surely can't be the way to
go.

Bill wrote:

BM> I don't see how storing the SQL in some different location is the
BM> correct way to fix anything?

That was my original suggestion, and I agree it was naive. But I don't
think that is what Peter is suggesting. I think the idea is that
parameterised prepared statements compile the SQL statement before the
user input is added via the parameters, making it impossible for user
input to modify the actual SQL statement.

>From the practical point of view, it surely seems easier to adopt a
particular style of programming ("any query using untrusted data MUST
be a parameterised prepared statement") than to analyse each and every
untrusted parameter for attack signatures? Or am I missing something
here?

-- 
Geoff Caplan
Vario Software
(+44) 121-515 1154 


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [GENERAL] Sql injection attacks

2004-07-25 Thread Geoff Caplan
Hi folks,

Peter Eisentraut wrote:

PE> If you use prepared statements (the details of which vary by >>
PE> programming language), you should be quite safe.

Peter - thanks for the suggestion. You are right: a poorly designed
function might simply concatenate the injected code - I hadn't really
thought it through. The key seems to be to treat the unsafe string as
a value so it can't leak out into the statement, and a parameterised
prepared statement would do this effectively, as you suggest. Very
elegant...

Bill Moran wrote:

BM> To protect yourself from SQL injections, just pass all your data through
BM> PQescapeString()

I'm no expert, but the papers I have been reading suggest that the
usual hygene advice such as don't display DB error messages and escape
unsafe strings doesn't cover all types of attack. See, for example,
this:

http://www.net-security.org/article.php?id=571

But so far as I can see, Peter's suggestion should provide a workable
robust solution. So thanks again!

-- 
Geoff Caplan
Vario Software Ltd
(+44) 121-515 1154 


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


[GENERAL] Sql injection attacks

2004-07-25 Thread Geoff Caplan
Hi folks,

I'm new to Postgres and trying to get up to speed on the security
issues. There seems to be remarkably little Postgres specific stuff on
preventing SQL injection attacks.

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 to execute it as a stored procedure.

In SQL Server, this reportedly works because the syntax of the query
is pre-compiled, and the variables passed in are treated strictly as
data and cannot alter the syntax. So any malicious use of "AND",
"UNION", ";" etc in submitted data will fail.

Can anyone confirm that this would also apply to Postgres Query
Language (SQL) functions? The effectiveness of moving the queries into
the database against SQL injection attack would seem to depend on the
query engine internals. Will using the SQL functions provide the
robust protection I am looking for?

-- 
Geoff Caplan
Vario Software Ltd
(+44) 121-515 1154


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


[GENERAL] Re: Need for newbie friendly docs (was Newbie struggling...)

2001-04-26 Thread Geoff Caplan

Oliver Elphick

> There is an enormous amount of background knowledge assumed when
> you document an application, and this is necessary, or else every document
> would become a Windows-like spoon-feeder, which would spend so much
> time on basic stuff that it would never cover the real meat.
>
> I'm not sure that it is either possible or desirable for PostgreSQL to
> attempt to satisfy a newbie's need for basic training in Unix.
>

Well, I have spent a lot of time writing instructional material, and I think
it is a question of the right balance. You obviously have to assume the
basics, like file management. An issue like the one I got stuck on, on the
other hand, is not so basic (not covered in the thousands of pages of Unix
documentation I consulted) and could have been explained with a single line
example.

In many ways it is a matter of mindset - when experienced people are writing
it is difficult for them to visualise the roadblocks that will catch out
those with less knowledge. More beginner friendly docs don't need to be much
more verbose - it's about  testing them and pinpointing the points of
difficulty.

The docs have room for many pages on how to do a SELECT, which is covered in
detail in every SQL primer, so there is surely no reason why setup should
not be covered a bit more clearly. Postgres is not so hard to use, but it is
a bit of a pig to administer, and the docs are part of the problem.

But I do understand that top quality docs require specific skills and
resources which it is perhaps unreasonable to expect from an open source
project. It will probably take a commercial effort from GreatBridge or a
book to improve things. GreatBridge have made a start. I hope they continue
to test and develop their docs, and don't regard the job as done...

Geoff Caplan


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl



[GENERAL] Struggling to change default data location

2001-04-26 Thread Geoff Caplan

Hi folks

Having a nightmare changing the default data location in 7.1

I uninstalled and re-installed 7.1 on RedHat 6.2 from the rpms with a
clean system. With the help of this list, I have set $PGDATA in my
shell config file and exported the value.

Postgres utilities such as initdb now recognise $PGDATA and I have
setup a system at my desired location.

initdb does not write a postmaster.opt file at the new location. On
system startup, it does write the .opt file to /var/lib/pgsql/data.
Editing this file with the new datapath does not change the behaviour
below.

At this stage - here is what I get...

$ /usr/bin/pg_ctl -D /www/dbdata -l logfile start
postmaster successfully started
$ pg_ctl status
pg_ctl: postmaster or postgres is not running
$ ps ax | grep postmaster
582 ?S  0:00 /usr/bin/postmaster -D /var/lib/pgsql/data

Please note:

- postmaster is running, but pg_ctl can't find it
- postmaster has started with the default datapath and is ignoring
  $PGDATA

I get the same result if I launch automatically during startup.

Can anyone please help me make some sense of this? I am losing the
will to live...

Geoff Caplan



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])



[GENERAL] Newbie struggling to set $PGDATA

2001-04-25 Thread Geoff Caplan

Hello Steve,

Thursday, April 19, 2001, 4:53:58 PM, you wrote:


SW> I just upgraded from 7.0.3 to  7.1 (using the RH rpms) with no 
SW> major problems.  Nice!

SW> However, I'm getting some strange behaviour from the init
SW> script (/etc/rc.d/init.d/postgresql).  In particular, a
SW> restart when the database is running fails because the
SW> "sleep 2" in stop() is no longer long enough (on a dual-cpu
SW> PIII/650 machine!).  So "pidof postmaster" returns a non-null
SW> value and *that* results in a syntax error:

SW>   Checking postgresql installation:  [  OK  ]
SW>   ./postgresql: [: 18209: unary operator expected

SW> (I think the test should become something like "if [ -n "$pid" ];..."
SW> instead of just "if [ $pid ]", which at least prevents the
SW> syntax error...)

SW> Of course, fixing the syntax error isn't the main problem, which
SW> is that the shutdown of the old postmaster(s) hasn't completed yet,
SW> resulting in a "false positive" from the pidof operation.

SW> I bumped the "sleep 2" up to "sleep 5" and the problem went away.
SW> Surely there's a better fix?

Hi

Please help out a Linx/Postgres newbie.

I simply want to set the $PGDATA environmental variable, but can't
figure out how. The docs assume you already know...

I have tried setting it in my bash /etc/profile configuration file,
and it shows up ok if I "echo $PGDATA" in the shell. But none of the
postgres utilities such as "initdb" seem to be able to find it.

What don't I understand? I have already checked the docs/GreatBridge
manual/faqs/archive, so I would very much appreciate some help.

Geoff Caplan



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



[GENERAL] Strange problems with phpPgAdmin

2001-03-30 Thread Geoff Caplan

Hi folks

My installation of phpPgAdmin has suddenly stopped working. I am not
very experienced in this area and have run out of ideas. Any pointers
would be much appreciated.

THE SYMPTOMS:

- To summarise, I get all the forms primed with the initial data
  from the default DB, but it won't run any queries via links or
  fields.

- Either nothing happens, I get a duplicate LH pane, or I get an
  error. For example if I click on "select" I get the message:

  Warning: PostgreSQL query failed:
  ERROR: Relation '' does not exist in /www/htdocs/phpPgAdmin/tbl_select.php on line 12
  PostgreSQL said: ERROR: Relation '' does not exist
  Your query: SELECT * FROM "" LIMIT 1

WHAT I HAVE CHECKED

- I am logging on as the SU who owns all the databases

- PHP/Postgres is working fine - I can access the databases via psql
  and PHP scripts without problems.

- I re-intalled phpPgAdmin from scratch.

So, advice would be very welcome - it's a great app and I am missing
it!

Geoff Caplan
Caplan Associates

PS I did post this to the phpPgAdmin specialist list but without
reply. Sorry for the cross posting, but I am very keen to get this
fixed.



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



[GENERAL] Strange problems with phpPgAdmin

2001-03-30 Thread Geoff Caplan

Hi folks

My installation of phpPgAdmin has suddenly stopped working. I am not
very experienced in this area and have run out of ideas. Any pointers
would be much appreciated.

THE SYMPTOMS:

- To summarise, I get all the forms primed with the initial data
  from the default DB, but it won't run any queries via links or
  fields.

- Either nothing happens, I get a duplicate LH pane, or I get an
  error. For example if I click on "select" I get the message:

  Warning: PostgreSQL query failed:
  ERROR: Relation '' does not exist in /www/htdocs/phpPgAdmin/tbl_select.php on line 12
  PostgreSQL said: ERROR: Relation '' does not exist
  Your query: SELECT * FROM "" LIMIT 1

WHAT I HAVE CHECKED

- I am logging on as the SU who owns all the databases

- PHP/Postgres is working fine - I can access the databases via psql
  and PHP scripts without problems.

- I re-intalled phpPgAdmin from scratch.

So, advice would be very welcome - it's a great app and I am missing
it!

Geoff Caplan
Caplan Associates

PS I did post this to the phpPgAdmin specialist list but without
reply. Sorry for the cross posting, but I am very keen to get this
fixed.



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]