"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,
-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
"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.
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
"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 stan
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 w
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 i
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-l
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:
SELEC
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
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
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
h
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 t
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 tha
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 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 y
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 wo
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 w
* 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 se
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?
http://sourceforge.net/projects/libd
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
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 conf
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 volum
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
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 expect
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
[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 ta
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 w
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
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
"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 performi
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
> > > f
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 tab
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 th
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 rebuildin
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 alway
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 ve
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
> > > > i
"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
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 w
> 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.
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
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
43 matches
Mail list logo
