Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
pgbfprod=# select sysname, snapshot from build_status_log where
branch = 'HEAD' and log_stage = 'check.log' and log_text ~ $$\+
ERROR: canceling statement due to statement timeout$$;
sysname | snapshot
On Fri, 2008-04-25 at 09:10 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
I'm now happy that we can get a spec-compliant end result by always
forcing NOT MATCHED rules to occur before MATCHED rules, when we have at
least one unique index.
... and raise an ERROR when there is no
I don't understand this if it's calling option 2 the monolithic
implementation. I was intending that the values be permanent tokens if
you like, so that ZERO rewriting would be required for any types of
modification. So I don't see where locking comes in. I don't want
rewriting either.
I
On 4/25/08, Robert Treat [EMAIL PROTECTED] wrote:
On Thursday 24 April 2008 23:40, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Perhaps a better option would be to implement Merge per spec, and then
implement a replace into command for the oltp scenario. This way you
Bryce Nesbitt [EMAIL PROTECTED] writes:
Unless they are in the habit of doing:
# COLUMNS=$COLUMNS ls -C |cat
Some of us are actually in the habit of doing that because it's easier to use
the standard interface than remembering the different command-line option for
each command. I quite often
On Mon, 2008-04-28 at 11:57 +0300, Marko Kreen wrote:
On 4/25/08, Robert Treat [EMAIL PROTECTED] wrote:
On Thursday 24 April 2008 23:40, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Perhaps a better option would be to implement Merge per spec, and then
implement a
Hi all,
I am working on implementation of custom C SRF for our team. The SRF uses
SFRM_ValuePerCall mode. I know that sometimes even in SFRM_ValuePerCall mode
all the rows returned from SRF are materialized (for performing JOINs, for
example). But it looks like even in cases when SELECT is very
dv @ nabble wrote:
I am working on implementation of custom C SRF for our team. The SRF uses
SFRM_ValuePerCall mode. I know that sometimes even in SFRM_ValuePerCall
mode
all the rows returned from SRF are materialized (for performing JOINs,
for
example).
Yep, they are unfortunately always
On Mon, Apr 28, 2008 at 2:24 PM, Zeugswetter Andreas OSB SD
[EMAIL PROTECTED] wrote:
I think you are not considering existing btree indexes here
(for the reordering case) ?
You're quite right, I had not considered existing indexes. There's no
easy way to deal with that other than rebuilding
Shane Ambler wrote:
Andrew Sullivan wrote:
Maybe because there's a perfectly functional archive link in the mail
headers? And because there's an RFC that tells us how such headers
are supposed to work?
As a lot of people use gui apps, (I do seem to recall that mail cli
shows the full
if you need a scrollable cursor for a prepared statement (to fetch
single rows from huge result sets)
while still being able to execute statements on the same connection
you can do it this way:
PGresult* res = PQprepare( con, statement1, declare cu1 scroll
cursor with hold for select * from table
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
While looking over the statistics-for-functions patch
(http://archives.postgresql.org/pgsql-patches/2008-03/msg00300.php),
I came back to a thought I've had before - why do we keep one
function per
Heikki Linnakangas [EMAIL PROTECTED] writes:
dv @ nabble wrote:
I am working on implementation of custom C SRF for our team. The SRF uses
SFRM_ValuePerCall mode. I know that sometimes even in SFRM_ValuePerCall
mode
all the rows returned from SRF are materialized (for performing JOINs,
for
On Sun, Apr 27, 2008 at 11:58:01AM -0400, Alvaro Herrera wrote:
So the proper thing to do is complain to the writer of the GUI app so
that it has an option for showing the list headers, perhaps adding a
menu entry when they are found.
At least in the case of Thunderbird, you already have an
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
sysname | snapshot |branch
-+-+---
lionfish | 2007-04-19 09:30:27 | REL8_2_STABLE
lionfish | 2007-05-29 23:30:07 | REL8_1_STABLE
lionfish | 2007-09-22 23:30:07 | REL8_1_STABLE
lionfish
Brendan Jurd escribió:
Here's my attempt to remove the typename field from A_Const. There
were a few places (notably flatten_set_variable_args() in guc.c, and
typenameTypeMod() in parse_type.c) where the code expected to see an
A_Const with a typename, and I had to adjust for an A_Const
[EMAIL PROTECTED] (Andrew Dunstan) writes:
Raphaël Jacquot wrote:
would seem like a good idea, no ?
http://www.murrayc.com/blog/permalink/2008/04/25/postgresql-has-no-bugzilla/
Before you come trolling on this (or any other) subject, please read
the voluminous debates that have taken place
Alvaro Herrera [EMAIL PROTECTED] writes:
Brendan Jurd escribió:
Here's my attempt to remove the typename field from A_Const. There
were a few places (notably flatten_set_variable_args() in guc.c, and
typenameTypeMod() in parse_type.c) where the code expected to see an
A_Const with a
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Brendan Jurd escribi�:
Here's my attempt to remove the typename field from A_Const. There
were a few places (notably flatten_set_variable_args() in guc.c, and
typenameTypeMod() in parse_type.c) where the code expected to see an
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
They're logically different things, and after I get done putting a parse
location field into A_Const, they'll still be physically different too.
Aha. Are you working from Brendan's patch? I was going to commit it.
Sure, go ahead.
Chris Browne wrote:
[EMAIL PROTECTED] (Andrew Dunstan) writes:
Raphaël Jacquot wrote:
would seem like a good idea, no ?
http://www.murrayc.com/blog/permalink/2008/04/25/postgresql-has-no-bugzilla/
Before you come trolling on this (or any other) subject, please read
the
On Mon, Apr 28, 2008 at 11:55:18AM -0400, Chris Browne wrote:
Yes, it is certainly fair to observe that there have been voluminous
debates. But it will take a whole lot of trolling around in the
archives to figure out the shape of the *conclusions* of those
debates.
As one of those confused,
Hi,
As you know, SQL injection is the main security problem of databases today.
I think I found a solution: 'disabling literals'. Or you may call it
'enforcing the use of parameterized statements'. This means that SQL
statements with embedded user input are rejected at runtime. My
solution goes
Thomas,
What do you think about it? Do you think it makes sense to implement
this security feature in PostgreSQL as well? If not why not? Does
PostgreSQL have another solution or plan to solve the SQL injection
problem?
Have you seen Meredith's libdejector?
* Thomas Mueller ([EMAIL PROTECTED]) wrote:
As you know, SQL injection is the main security problem of databases today.
I think there's a fallacy there- it's the main security problem of
applications (particularly those on the web) today. It hasn't got much
at all to do with the database's
Hello,
I would like to write a patch that provides the command:
VACUUM SUMMARY
This was discussed briefly here:
http://archives.postgresql.org/pgsql-performance/2007-10/msg00165.php
I know there are other plans for 8.4 but I was wondering if those plans
appear to be happening or not? I don't
Joshua D. Drake wrote:
I know there are other plans for 8.4 but I was wondering if those plans
appear to be happening or not? I don't want to waste people's time on
the patch but if we aren't going to change the FSM stuff for 8.4, I as
a DBA would find VACUUM SUMMARY useful.
I think it would
Alvaro Herrera escribió:
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
They're logically different things, and after I get done putting a parse
location field into A_Const, they'll still be physically different too.
Aha. Are you working from
As you know, SQL injection is the main security problem of databases
today.
I think I found a solution: 'disabling literals'. Or you may call it
'enforcing the use of parameterized statements'. This means that SQL
statements with embedded user input are rejected at runtime. My
solution goes
Alvaro Herrera [EMAIL PROTECTED] writes:
I came up with the attached patch.
I wasn't envisioning anything anywhere near this invasive. We only
need locations on constants in a few contexts, I think.
BTW, you broke _equalAConst() ... it was a bad idea anyway to recast
it on the assumption that
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
I came up with the attached patch.
I wasn't envisioning anything anywhere near this invasive. We only
need locations on constants in a few contexts, I think.
Aha. OK, I'll commit the original patch and let you deal with the rest
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, I'm now wondering if the location should be added to Value as well,
so that it can be passed down to Const?
Just for the record, we don't want it in Const. Parse locations are
only useful in the raw grammar output, mainly because they aren't
Alvaro Herrera [EMAIL PROTECTED] writes:
Joshua D. Drake wrote:
I know there are other plans for 8.4 but I was wondering if those plans
appear to be happening or not? I don't want to waste people's time on
the patch but if we aren't going to change the FSM stuff for 8.4, I as
a DBA would find
On Tue, Apr 29, 2008 at 7:00 AM, PFC [EMAIL PROTECTED] wrote:
I have found that the little bit of code posted afterwards did eliminate
SQL holes in my PHP applications with zero developer pain, actually it is
MORE convenient to use than randomly pasting strings into queries.
You just call
On Mon, Apr 28, 2008 at 08:55:34PM +0200, Thomas Mueller wrote:
As you know, SQL injection is the main security problem of databases today.
I think I found a solution: 'disabling literals'.
I personally think this is wrong, I often have schemas that mean I have
to do things like:
SELECT
Gregory Stark wrote:
Bryce Nesbitt [EMAIL PROTECTED] writes:
Unless they are in the habit of doing:
# COLUMNS=$COLUMNS ls -C |cat
Some of us are actually in the habit of doing that because it's easier to use
the standard interface than remembering the different command-line option for
Tom Lane wrote:
[EMAIL PROTECTED] (Alvaro Herrera) writes:
Add generate_subscripts, a series-generation function which generates an
array's subscripts.
Why are these marked volatile in pg_proc? Surely they generate the
same outputs given the same inputs, and therefore qualify as
Alvaro Herrera [EMAIL PROTECTED] writes:
I'll change the four generate_series variants too -- they are marked
volatile as well.
I don't think the system actually pays much attention to the volatility
marking of set-returning functions at the moment, so it wouldn't be too
surprising if they were
Bruce Momjian [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Bryce Nesbitt [EMAIL PROTECTED] writes:
Unless they are in the habit of doing:
# COLUMNS=$COLUMNS ls -C |cat
Some of us are actually in the habit of doing that because it's easier to use
the standard interface than
Gregory Stark wrote:
Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
but that seems confusing.
We could always read COLUMNS early on before readline is initialized and stash
the value away in a variable. But...
We would only look at COLUMNS if the ioctl for
Bruce Momjian [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
but that seems confusing.
We could always read COLUMNS early on before readline is initialized and
stash
the value away in a variable. But...
We
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Increase the statement_timeout value used in the prepared_xacts
regression test. We have seen some buildfarm failures that seem
to be due to this limit being unexpectedly exceeded when the machine
is under load.
Just as a data point, I
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Increase the statement_timeout value used in the prepared_xacts
regression test. We have seen some buildfarm failures that seem
to be due to this limit being unexpectedly exceeded when the machine
is under load.
Just as a data point, I thought I
43 matches
Mail list logo
