Re: [HACKERS] Patch for checking file parameters to psql before password prompt

On 12/29/12 3:36 PM, Stephen Frost wrote: Perhaps there's a better way to handle that? Responding to feedback would be a nice start. This submissions has been dead at "Waiting on Author" for at least 3 months now. Time to give it the "Returned with Feedback" boot and see if it comes around

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 4 April 2013 15:11, Tom Lane wrote: > Brendan Jurd writes: >> My thought was that on-disk zero-D arrays should be converted into >> empty 1-D arrays (with default lower bounds of course) when they are >> read by array_recv. > > Huh? array_recv would not get applied to datums coming off of dis

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd writes: > My thought was that on-disk zero-D arrays should be converted into > empty 1-D arrays (with default lower bounds of course) when they are > read by array_recv. Huh? array_recv would not get applied to datums coming off of disk. The only way to make this 100% transparent wo

Re: [HACKERS] Page replacement algorithm in buffer cache

On 4/2/13 11:54 AM, Robert Haas wrote: But, having said that, I still think the best idea is what Andres proposed, which pretty much matches my own thoughts: the bgwriter needs to populate the free list, so that buffer allocations don't have to wait for linear scans of the buffer array. I was h

Re: [HACKERS] Multi-pass planner

On Fri, Aug 21, 2009 at 6:54 PM, decibel wrote: > Would it? Risk seems like it would just be something along the lines of > the high-end of our estimate. I don't think confidence should be that hard > either. IE: hard-coded guesses have a low confidence. Something pulled > right out of most_commo

Re: [HACKERS] corrupt pages detected by enabling checksums

On 2013-04-04 02:58:43 +0200, Andres Freund wrote: > On 2013-04-03 20:45:51 -0400, Tom Lane wrote: > > and...@anarazel.de (Andres Freund) writes: > > > Looking at the page lsn's with dd I noticed something peculiar: > > > > > page 0: > > > 01 00 00 00 18 c2 00 31 => 1/3100C218 > > > page 1: > > > 0

Re: [HACKERS] Page replacement algorithm in buffer cache

On Thu, Apr 4, 2013 at 3:41 AM, Tom Lane wrote: > I think the original vision of the clock sweep algorithm included the > idea that different backends could be running the sweep over different > parts of the buffer ring concurrently. If we could get rid of the need > to serialize that activity, i

Re: [HACKERS] Interesting post-mortem on a near disaster with git

On Wed, Apr 3, 2013 at 6:18 PM, Jim Nasby wrote: >> > What about rdiff-backup? I've set it up for personal use years ago >> >> > (via the handy open source bash script backupninja) years ago and it >> >> > has a pretty nice no-frills point-in-time, self-expiring, file-based >> >> > automatic b

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 4 April 2013 01:10, Tom Lane wrote: > I think though that the upthread argument that we'd have multiple > interpretations of the same thing is bogus. To me, the core idea that's > being suggested here is that '{}' should mean a zero-length 1-D array, > not a zero-D array as formerly. We would

Re: [HACKERS] Minor erratum for 9.2.4 release notes

2013/4/4 Tom Lane : > Ian Lawrence Barwick writes: >> I guess the 9.2.4 release notes haven't been finalized yet; apologies >> if this is already addressed, but following sentence: > >> >> Also, if you are upgrading from a version earlier than 9.2.2, >> see the release notes for 9.2.2.

Re: [HACKERS] Minor erratum for 9.2.4 release notes

Ian Lawrence Barwick writes: > I guess the 9.2.4 release notes haven't been finalized yet; apologies > if this is already addressed, but following sentence: > > Also, if you are upgrading from a version earlier than 9.2.2, > see the release notes for 9.2.2. > > should read: >

Re: [HACKERS] Interesting post-mortem on a near disaster with git

On 3/26/13 6:42 AM, Cédric Villemain wrote: Le lundi 25 mars 2013 19:35:12, Daniel Farina a écrit : > On Mon, Mar 25, 2013 at 11:07 AM, Stefan Kaltenbrunner > > wrote: > >> Back when we used CVS for quite a few years I kept 7 day rolling > >> snapshots of the CVS repo, against just suc

[HACKERS] Minor erratum for 9.2.4 release notes

I guess the 9.2.4 release notes haven't been finalized yet; apologies if this is already addressed, but following sentence: Also, if you are upgrading from a version earlier than 9.2.2, see the release notes for 9.2.2. should read: Also, if you are upgrading from a versio

Re: [HACKERS] corrupt pages detected by enabling checksums

On 2013-04-03 20:45:51 -0400, Tom Lane wrote: > and...@anarazel.de (Andres Freund) writes: > > Looking at the page lsn's with dd I noticed something peculiar: > > > page 0: > > 01 00 00 00 18 c2 00 31 => 1/3100C218 > > page 1: > > 01 00 00 00 80 44 01 31 => 1/31014480 > > page 10: > > 01 00 00 00

Re: [HACKERS] corrupt pages detected by enabling checksums

and...@anarazel.de (Andres Freund) writes: > Looking at the page lsn's with dd I noticed something peculiar: > page 0: > 01 00 00 00 18 c2 00 31 => 1/3100C218 > page 1: > 01 00 00 00 80 44 01 31 => 1/31014480 > page 10: > 01 00 00 00 60 ce 05 31 => 1/3105ce60 > page 43: > 01 00 00 00 58 7a 16 31 =

Re: [HACKERS] Page replacement algorithm in buffer cache

Greg Stark writes: > I'm still skeptical about the idea of a "freelist". That just seems like a > terrible point of contention. However perhaps that's because I'm picturing > an LRU linked list. Perhaps the right thing is to maintain a pool of > buffers in some less contention-prone data structure

Re: [HACKERS] corrupt pages detected by enabling checksums

On 2013-04-04 02:28:32 +0200, Andres Freund wrote: > On 2013-04-04 01:52:41 +0200, Andres Freund wrote: > > On 2013-04-03 15:57:49 -0700, Jeff Janes wrote: > > > I've changed the subject from "regression test failed when enabling > > > checksum" because I now know they are totally unrelated. > > >

Re: [HACKERS] Regex with > 32k different chars causes a backend crash

On Wed, Apr 03, 2013 at 08:09:15PM +0300, Heikki Linnakangas wrote: > --- a/src/include/regex/regguts.h > +++ b/src/include/regex/regguts.h > @@ -148,6 +148,7 @@ > typedef short color; /* colors of characters */ > typedef int pcolor; /* what color promotes

Re: [HACKERS] corrupt pages detected by enabling checksums

On Wed, 2013-04-03 at 15:57 -0700, Jeff Janes wrote: > You don't know that the cluster is in the bad state until after it > goes through recovery because most crashes recover perfectly fine. So > it would have to make a side-copy of the cluster after the crash, then > recover the original and

Re: [HACKERS] corrupt pages detected by enabling checksums

On 2013-04-04 01:52:41 +0200, Andres Freund wrote: > On 2013-04-03 15:57:49 -0700, Jeff Janes wrote: > > I've changed the subject from "regression test failed when enabling > > checksum" because I now know they are totally unrelated. > > > > My test case didn't need to depend on archiving being on

Re: [HACKERS] patch to add \watch to psql

2013/4/3 Will Leinweber : > Here is an updated patch that addresses several of the points brought up so > far, such as the sleep, internationalization banner, and zero wait check, > and it removes the premature input check. > > Unfortunately rl_clear_screen() is not included at all in libedit, caus

Re: [HACKERS] spoonbill vs. -HEAD

Stefan Kaltenbrunner writes: > On 04/03/2013 12:59 AM, Tom Lane wrote: >> BTW, on further thought it seems like maybe this is an OpenBSD bug, >> at least in part: what is evidently happening is that the temporary >> blockage of SIGINT during the handler persists even after we've >> longjmp'd back

Re: [HACKERS] patch to add \watch to psql

Here is an updated patch that addresses several of the points brought up so far, such as the sleep, internationalization banner, and zero wait check, and it removes the premature input check. Unfortunately rl_clear_screen() is not included at all in libedit, causing compilation to fail, and I was

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 04/04/13 11:55, Jim Nasby wrote: On 4/3/13 10:34 AM, Gavin Flower wrote: Maybe we should adopt the famous compromise of '0.5'? +0.5. ;P Far too positive for our grim world! How about '-0,5' instead? :-) I notice you call yourself a 'Data Architect' - never too sure If I should call mys

Re: [HACKERS] corrupt pages detected by enabling checksums

On 2013-04-03 15:57:49 -0700, Jeff Janes wrote: > I've changed the subject from "regression test failed when enabling > checksum" because I now know they are totally unrelated. > > My test case didn't need to depend on archiving being on, and so with a > simple tweak I rendered the two issues orth

Re: [HACKERS] Page replacement algorithm in buffer cache

On Wed, Apr 3, 2013 at 3:00 PM, Robert Haas wrote: > The main hesitation I've had about actually implementing such a scheme > is that I find it a bit unappealing to have a background process > dedicated to just this. But maybe it could be combined with some of > the other ideas presented here.

Re: [HACKERS] CREATE EXTENSION BLOCKS

On Apr 3, 2013, at 11:41 AM, Alvaro Herrera wrote: >> Oh, they are not unique per-schema? I guess they are global to the database >> but then their objects are in the specified schema, then. > > Right -- an extension is not considered to live within a schema, they > are database-global. The ob

Re: [HACKERS] Clang compiler warning on 9.3 HEAD

On Wed, Apr 3, 2013 at 11:52 PM, Will Leinweber wrote: > On ref 8507907 when compiling with clang on os x, I got this warning which > seems like a possible bug. > > I thought to report this because I imagine clang isn't frequently used > day-to-day by most. I actually reported a bug that was thro

[HACKERS] corrupt pages detected by enabling checksums

I've changed the subject from "regression test failed when enabling checksum" because I now know they are totally unrelated. My test case didn't need to depend on archiving being on, and so with a simple tweak I rendered the two issues orthogonal. On Wed, Apr 3, 2013 at 12:15 PM, Jeff Davis wro

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 4/3/13 10:34 AM, Gavin Flower wrote: Maybe we should adopt the famous compromise of '0.5'? +0.5. ;P -- Jim C. Nasby, Data Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@po

[HACKERS] Clang compiler warning on 9.3 HEAD

On ref 8507907 when compiling with clang on os x, I got this warning which seems like a possible bug. I thought to report this because I imagine clang isn't frequently used day-to-day by most. dependency.c:213:36: warning: implicit conversion from enumeration type 'ObjectClass' (aka 'enum ObjectC

Re: [HACKERS] Drastic performance loss in assert-enabled build in HEAD

Kevin Grittner writes: > Tom Lane wrote: >>> In fact, I'm going to go further and say that I do not like the >>> entire concept of scannability, either as to design or >>> implementation, and I think we should just plain rip it out. > To be honest, I don't think I've personally seen a single use

Re: [HACKERS] c language functions

I see, that's true. I'm returning unknown type, there is a little more overhead. But it's working now. =] Thanks for the help guys! On Wed, Apr 3, 2013 at 6:17 PM, Robert Haas wrote: > On Wed, Apr 3, 2013 at 3:25 PM, Rodrigo Barboza > wrote: > > Well, I was checking inside my function the type

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

On Wed, Apr 3, 2013 at 2:54 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Apr 2, 2013 at 12:19 PM, Peter Eisentraut wrote: >>> It's weird that SET LOCAL and SET SESSION actually *set* the value, and >>> the second key word determines how long the setting will last. SET >>> PERSISTENT doe

Re: [HACKERS] c language functions

On Wed, Apr 3, 2013 at 3:25 PM, Rodrigo Barboza wrote: > Well, I was checking inside my function the type of the second argument and > switching between the allowed types. > This way kind of does the same thing of many functions, doesn't it? Sure, except that it will also call your function when

Re: [HACKERS] Drastic performance loss in assert-enabled build in HEAD

Tom Lane wrote: > Robert Haas writes: >> Tom Lane wrote: >>> In fact, I'm going to go further and say that I do not like the >>> entire concept of scannability, either as to design or >>> implementation, and I think we should just plain rip it out. > >> This has been my feeling from the beginni

Re: [HACKERS] commit dfda6ebaec67 versus wal_keep_segments

On Wed, Apr 3, 2013 at 11:14 AM, Heikki Linnakangas wrote: > On 03.04.2013 18:58, Jeff Janes wrote: > >> On Tue, Apr 2, 2013 at 10:08 PM, Jeff Janes wrote: >> >> This commit introduced a problem with wal_keep_segments: >>> >>> commit dfda6ebaec6763090fb78b458a979b**558c50b39b >>> >> >> The prob

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 2013-04-04 08:03:03 +1300, Gavin Flower wrote: > On 04/04/13 07:58, Kevin Grittner wrote: > >Gavin Flower wrote: > > > >>Anyhow, I think we should standardise on zero as the initial > >>index to be as consistent as practicable. > >If you want to suggest a default of zero for the first subscript

Re: [HACKERS] c language functions

Well, I was checking inside my function the type of the second argument and switching between the allowed types. This way kind of does the same thing of many functions, doesn't it? On Wed, Apr 3, 2013 at 3:39 PM, Tom Lane wrote: > Rodrigo Barboza writes: > > Why not useful? > > If I don't make

Re: [HACKERS] regression test failed when enabling checksum

On Mon, 2013-04-01 at 19:51 -0700, Jeff Janes wrote: > I've reproduced the problem, this time in block 74 of relation > base/16384/4931589, and a tarball of the data directory is here: > > > https://docs.google.com/file/d/0Bzqrh1SO9FcELS1majlFcTZsR0k/edit?usp=sharing > > > > (the table is in

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 04/04/13 07:58, Kevin Grittner wrote: Gavin Flower wrote: Anyhow, I think we should standardise on zero as the initial index to be as consistent as practicable. If you want to suggest a default of zero for the first subscript of an array in SQL, please don't confuse the issue by using any

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 04/04/13 05:36, David E. Wheeler wrote: On Apr 3, 2013, at 9:30 AM, Tom Lane wrote: Fortran ... Basic ... actually I'd have thought that zero was a minority position. Fashions change I guess. I say we turn the default lower bound up to 11. David In keeping with the level of irrationali

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Gavin Flower wrote: > Anyhow, I think we should standardise on zero as the initial > index to be as consistent as practicable. If you want to suggest a default of zero for the first subscript of an array in SQL, please don't confuse the issue by using any form of the word "standard" in that prop

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

Robert Haas writes: > On Tue, Apr 2, 2013 at 12:19 PM, Peter Eisentraut wrote: >> It's weird that SET LOCAL and SET SESSION actually *set* the value, and >> the second key word determines how long the setting will last. SET >> PERSISTENT doesn't actually set the value. I predict that this will

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 04/04/13 05:30, Tom Lane wrote: Zero as the default lower bound is consistent with most languages (especially the common ones like C, C++, Java, & Python), in fact I don't remember any language where that is not the case (ignoring SQL) - and I've written programs in about 20 languages. Fortra

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 2013-04-04 07:42:36 +1300, Gavin Flower wrote: > On 04/04/13 05:21, Pavel Stehule wrote: > > > >> > >>Pavel > >> > >ALOGOL 60 was zero based by default, as I remember > >deliberately setting the lower bound to 1, I managed to avoid > >PASCAL and I only glanced at

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 04/04/13 05:21, Pavel Stehule wrote: Pavel ALOGOL 60 was zero based by default, as I remember deliberately setting the lower bound to 1, I managed to avoid PASCAL and I only glanced at ADA. http://en.wikipedia.org/wiki/Comparison_of_programming_langua

Re: [HACKERS] CREATE EXTENSION BLOCKS

David E. Wheeler wrote: > On Apr 3, 2013, at 2:37 AM, Albe Laurenz wrote: > > > I'd expect one of the CREATE EXTENSION commands to succeed > > and the others to block until the transaction is committed, > > then to fail with 'extension "oracle_fdw" already exists'. > > > > If that is what happen

Re: [HACKERS] c language functions

Rodrigo Barboza writes: > Why not useful? > If I don't make it receive anyelement, I will have to create an add > function for each type. If you make it anyelement, then you're contracting to be able to add any datatype whatsoever to a my_uint. This is nonsensical. You'd be better off declaring

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Tom Lane wrote: > Fortran ... Basic ... actually I'd have thought that zero was a > minority position.  Fashions change I guess. When I started programming the top four languages for business programming were COBOL, BASIC, RPG II, and assembly language. (Pascal and C came later, and I never saw

Re: [HACKERS] regression test failed when enabling checksum

On Wed, 2013-04-03 at 09:48 -0700, Jeff Janes wrote: > And why did those uninitialized pages trigger warnings when they were > autovacced, but not when they were seq scanned in a query? > A scan won't trigger that warning. Empty pages are sometimes the expected result of a crash when the file is

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 3 April 2013 15:10, Tom Lane wrote: > I think though that the upthread argument that we'd have multiple > interpretations of the same thing is bogus. To me, the core idea that's > being suggested here is that '{}' should mean a zero-length 1-D array, > not a zero-D array as formerly. We would

Re: [HACKERS] commit dfda6ebaec67 versus wal_keep_segments

On 03.04.2013 18:58, Jeff Janes wrote: On Tue, Apr 2, 2013 at 10:08 PM, Jeff Janes wrote: This commit introduced a problem with wal_keep_segments: commit dfda6ebaec6763090fb78b458a979b558c50b39b The problem seems to be that the underflow warned about is happening, because the check to guard

Re: [HACKERS] Regex with > 32k different chars causes a backend crash

Heikki Linnakangas writes: > Attached is a patch to add the overflow check. I used the error message > "too many distinct characters in regex". That's not totally accurate, > because there isn't a limit on distinct characters per se, but on the > number of colors. Conceivably, you could have a

Re: [HACKERS] c language functions

Why not useful? If I don't make it receive anyelement, I will have to create an add function for each type. Correct me if I'm wrong. On Wed, Apr 3, 2013 at 2:27 PM, Robert Haas wrote: > On Wed, Apr 3, 2013 at 11:26 AM, Rodrigo Barboza > wrote: > > Hello. > > I'm trying to create a generic add

Re: [HACKERS] Drastic performance loss in assert-enabled build in HEAD

Robert Haas writes: > On Wed, Apr 3, 2013 at 10:59 AM, Tom Lane wrote: >> In fact, I'm going to go further and say that I do not like the entire >> concept of scannability, either as to design or implementation, and >> I think we should just plain rip it out. > This has been my feeling from the

Re: [HACKERS] c language functions

On Wed, Apr 3, 2013 at 11:26 AM, Rodrigo Barboza wrote: > Hello. > I'm trying to create a generic add function. > I have defined a type my_uint and it needs a '+' operator. > This operator should work like normal int + int operation. > The function is defined expecting arguments (my_uint, anyeleme

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

On Tue, Apr 2, 2013 at 12:19 PM, Peter Eisentraut wrote: > It's weird that SET LOCAL and SET SESSION actually *set* the value, and > the second key word determines how long the setting will last. SET > PERSISTENT doesn't actually set the value. I predict that this will be > a new favorite help-i

Re: [HACKERS] Regex with > 32k different chars causes a backend crash

On 03.04.2013 18:41, Tom Lane wrote: Heikki Linnakangas writes: On 03.04.2013 18:21, Tom Lane wrote: Obviously Henry didn't think that far ahead. I agree that throwing an error is the best solution, and that widening "color" is probably not what we want to do. You want to fix that, or shall

Re: [HACKERS] regression test failed when enabling checksum

On 2013-04-03 09:48:54 -0700, Jeff Janes wrote: > On Wed, Apr 3, 2013 at 2:31 AM, Andres Freund wrote: > > > > > > I just checked and unfortunately your dump doesn't contain all that much > > valid WAL: > > ... > > > > > > So just two checkpoint records. > > > > Unfortunately I fear that won't

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On Wed, Apr 3, 2013 at 12:36 PM, David E. Wheeler wrote: > On Apr 3, 2013, at 9:30 AM, Tom Lane wrote: >> Fortran ... Basic ... actually I'd have thought that zero was a >> minority position. Fashions change I guess. > > I say we turn the default lower bound up to 11. +1. I think that's clearl

Re: [HACKERS] regression test failed when enabling checksum

On Wed, Apr 3, 2013 at 2:31 AM, Andres Freund wrote: > > I just checked and unfortunately your dump doesn't contain all that much > valid WAL: > ... > > So just two checkpoint records. > > Unfortunately I fear that won't be enough to diagnose the problem, > could you reproduce it with a higher

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 04/03/2013 11:34 AM, Gavin Flower wrote: Zero as the default lower bound is consistent with most languages (especially the common ones like C, C++, Java, & Python), in fact I don't remember any language where that is not the case (ignoring SQL) - and I've written programs in about 20 lang

Re: [HACKERS] [sepgsql 2/3] Add db_schema:search permission checks

On Tue, Apr 2, 2013 at 2:22 PM, Kohei KaiGai wrote: > OK, please check the attached ones. Thanks. I reviewed the schema-search patch and I think it looks reasonable, but shouldn't we be calling the event OAT_NAMESPACE_SEARCH rather than OAT_SCHEMA_SEARCH? And, similarly, ObjectAccessNamespaceSe

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On Apr 3, 2013, at 9:30 AM, Tom Lane wrote: > Fortran ... Basic ... actually I'd have thought that zero was a > minority position. Fashions change I guess. I say we turn the default lower bound up to 11. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

Re: [HACKERS] Drastic performance loss in assert-enabled build in HEAD

On Wed, Apr 3, 2013 at 10:59 AM, Tom Lane wrote: > In fact, I'm going to go further and say that I do not like the entire > concept of scannability, either as to design or implementation, and > I think we should just plain rip it out. This has been my feeling from the beginning, so I'm happy to s

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

>> Zero as the default lower bound is consistent with most languages >> (especially the common ones like C, C++, Java, & Python), in fact >> I don't remember any language where that is not the case (ignoring >> SQL) - and I've written programs in about 20 languages. Fortran ... Basic ... actually

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

> >> Pavel >> >>ALOGOL 60 was zero based by default, as I remember deliberately >> setting the lower bound to 1, I managed to avoid PASCAL and I only glanced >> at ADA. >> > > > http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29 > > In Pascal and similar languages (Wi

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

2013/4/3 Gavin Flower > On 04/04/13 04:58, Pavel Stehule wrote: > > > > > 2013/4/3 Gavin Flower > >> On 04/04/13 03:02, Florian Pflug wrote: >> >>> On Apr3, 2013, at 15:30 , Andrew Dunstan wrote: >>> On 04/02/2013 02:46 PM, Florian Pflug wrote: > If we're going to break compatibi

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 04/04/13 04:58, Pavel Stehule wrote: 2013/4/3 Gavin Flower > On 04/04/13 03:02, Florian Pflug wrote: On Apr3, 2013, at 15:30 , Andrew Dunstan mailto:and...@dunslane.net>> wrote: On 04/02/2013 02:46 PM, Florian Pflug wrote:

Re: [HACKERS] CREATE EXTENSION BLOCKS

On Apr 3, 2013, at 2:37 AM, Albe Laurenz wrote: > I'd expect one of the CREATE EXTENSION commands to succeed > and the others to block until the transaction is committed, > then to fail with 'extension "oracle_fdw" already exists'. > > If that is what happens, it's what I'd expect since > extens

[HACKERS] track_activities is mostly broken

The point of turning off pgstat_track_activities is, IMO, to eliminate the overhead of updating one's PgBackendStatus entry in main memory. Commit 4f42b546 broke this, however, because it confused getting into the "reporting disabled" state with what should happen once already in the state. If you

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

2013/4/3 Gavin Flower > On 04/04/13 03:02, Florian Pflug wrote: > >> On Apr3, 2013, at 15:30 , Andrew Dunstan wrote: >> >>> On 04/02/2013 02:46 PM, Florian Pflug wrote: >>> If we're going to break compatibility, we should IMHO get rid of non-zero lower bounds all together. My guess is

Re: [HACKERS] commit dfda6ebaec67 versus wal_keep_segments

On Tue, Apr 2, 2013 at 10:08 PM, Jeff Janes wrote: > This commit introduced a problem with wal_keep_segments: > > commit dfda6ebaec6763090fb78b458a979b558c50b39b > The problem seems to be that the underflow warned about is happening, because the check to guard it was checking the wrong thing.

Re: [HACKERS] Regex with > 32k different chars causes a backend crash

Heikki Linnakangas writes: > On 03.04.2013 18:21, Tom Lane wrote: >> Obviously Henry didn't think that far ahead. I agree that throwing >> an error is the best solution, and that widening "color" is probably >> not what we want to do. You want to fix that, or shall I? > I can do it. I assume th

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 04/04/13 03:02, Florian Pflug wrote: On Apr3, 2013, at 15:30 , Andrew Dunstan wrote: On 04/02/2013 02:46 PM, Florian Pflug wrote: If we're going to break compatibility, we should IMHO get rid of non-zero lower bounds all together. My guess is that the number of affected users wouldn't be mu

[HACKERS] c language functions

Hello. I'm trying to create a generic add function. I have defined a type my_uint and it needs a '+' operator. This operator should work like normal int + int operation. The function is defined expecting arguments (my_uint, anyelement). I'm confused in retrieving the anyelement type, value and tha

Re: [HACKERS] Regex with > 32k different chars causes a backend crash

On 03.04.2013 18:21, Tom Lane wrote: Heikki Linnakangas writes: A regex with that many different colors is an extreme case, so I think it's enough to turn the assertion in newcolor() into a run-time check, and throw a "too many colors in regexp" error. Alternatively, we could expand 'color' fro

Re: [HACKERS] Regex with > 32k different chars causes a backend crash

Heikki Linnakangas writes: > A regex with that many different colors is an extreme case, so I think > it's enough to turn the assertion in newcolor() into a run-time check, > and throw a "too many colors in regexp" error. Alternatively, we could > expand 'color' from short to int, but that woul

[HACKERS] Regex with > 32k different chars causes a backend crash

While playing with Alexander's pg_trgm regexp patch, I noticed that the regexp library trips an assertion (if enabled) or crashes, when passed an input string that contains more than 32k different characters: select 'foo' ~ (select string_agg(chr(x),'') from generate_series(100, 35000) x) as n

Re: [HACKERS] Drastic performance loss in assert-enabled build in HEAD

[ sorry for being slow to respond, things are crazy this week ] Kevin Grittner writes: > Tom Lane wrote: >> Anyway, the immediate takeaway is that this represents a horribly >> expensive way for pg_dump to find out which matviews aren't >> scannable. The cheap way for it to find out would be if

Re: [HACKERS] Typo in FDW documentation

Albe Laurenz writes: > I found a small typo, patch attached. Drat, thought I'd fixed that before, but obviously not. Done now, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://

Re: [HACKERS] Typo in documentation for function to_json

On 04/03/2013 10:11 AM, Tom Lane wrote: Andrew Dunstan writes: I have a patch for this and other docs errors waiting in the wings. I will commit it when the current hiatus is done, some time tomorrow. There's no reason not to commit now. The blockage is on propagation to the anongit mirror,

Re: [HACKERS] Typo in documentation for function to_json

Andrew Dunstan writes: > I have a patch for this and other docs errors waiting in the wings. I > will commit it when the current hiatus is done, some time tomorrow. There's no reason not to commit now. The blockage is on propagation to the anongit mirror, not on what committers can do.

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Andrew Dunstan writes: > On 04/02/2013 02:46 PM, Florian Pflug wrote: >> If we're going to break compatibility, we should IMHO get rid of >> non-zero lower bounds all together. My guess is that the number of >> affected users wouldn't be much higher than for the proposed patch, >> and it'd allow l

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On Apr3, 2013, at 15:30 , Andrew Dunstan wrote: > On 04/02/2013 02:46 PM, Florian Pflug wrote: >> If we're going to break compatibility, we should IMHO get rid of >> non-zero lower bounds all together. My guess is that the number of >> affected users wouldn't be much higher than for the proposed p

Re: [HACKERS] Page replacement algorithm in buffer cache

On Tue, Apr 2, 2013 at 1:20 PM, Andres Freund wrote: > On 2013-04-02 12:56:56 -0400, Tom Lane wrote: >> Andres Freund writes: >> > On 2013-04-02 12:22:03 -0400, Tom Lane wrote: >> >> I agree in general, though I'm not sure the bgwriter process can >> >> reasonably handle this need along with what

[HACKERS] Typo in FDW documentation

I found a small typo, patch attached. Yours, Laurenz Albe fdw-doc.patch Description: fdw-doc.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Typo in documentation for function to_json

On Wed, Apr 3, 2013 at 10:32 PM, Andrew Dunstan wrote: > I have a patch for this and other docs errors waiting in the wings. I will > commit it when the current hiatus is done, some time tomorrow. > OK thanks. -- Michael

Re: [HACKERS] Typo in documentation for function to_json

On 04/03/2013 09:22 AM, Michael Paquier wrote: Hi all, While reading some documentation about json functions, I found a typo with the example used with function to_json. A bracket was missing. Please find attached the patch correcting that. I have a patch for this and other docs errors w

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 04/02/2013 02:46 PM, Florian Pflug wrote: On Apr1, 2013, at 13:43 , Robert Haas wrote: I don't think the current behavior is broken. I found it counterintuitive at first, but then I got used to it. It's reasonably self-consistent: arrays can't have empty dimensions, therefore the empty ar

Re: [HACKERS] in-catalog Extension Scripts and Control parameters (templates?)

Hi, Dimitri Fontaine writes: >> Documentation doesn't build, multiple errors. In addition to the reference >> pages, there should be a section in the main docs about these templates. > > I'm now working on that, setting up the documentation tool set. Fixed in the attached version 6 of the patch.

[HACKERS] Typo in documentation for function to_json

Hi all, While reading some documentation about json functions, I found a typo with the example used with function to_json. A bracket was missing. Please find attached the patch correcting that. Regards, -- Michael 20120403_to_json_typo.patch Description: Binary data -- Sent via pgsql-hackers

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On Apr1, 2013, at 13:43 , Robert Haas wrote: > I don't think the current behavior is broken. I found it > counterintuitive at first, but then I got used to it. It's reasonably > self-consistent: arrays can't have empty dimensions, therefore the > empty array is unique and dimensionless. Is that

Re: [HACKERS] Extra security measures for next week's releases

On Wed, Apr 3, 2013 at 12:09 PM, wrote: > Am 28.03.2013 18:03, schrieb Tom Lane: > >> The core committee has decided that one of the security issues due to be >> fixed next week is sufficiently bad that we need to take extra measures >> to prevent it from becoming public before packages containin

Re: [HACKERS] Extra security measures for next week's releases

Am 28.03.2013 18:03, schrieb Tom Lane: The core committee has decided that one of the security issues due to be fixed next week is sufficiently bad that we need to take extra measures to prevent it from becoming public before packages containing the fix are available. (This is a scenario we've d

Re: [HACKERS] CREATE EXTENSION BLOCKS

David E. Wheeler wrote: > I am working on scripts to copy data from Oracle via oracle_fdw. They each do > something like this: > > CREATE SCHEMA migrate_stuff; > SET search_path TO migrate_stuff,public; > CREATE EXTENSION oracle_fdw SCHEMA migrate_rules; > [...] > > Then I run them

Re: [HACKERS] regression test failed when enabling checksum

On 2013-04-01 19:51:19 -0700, Jeff Janes wrote: > On Mon, Apr 1, 2013 at 10:37 AM, Jeff Janes wrote: > > > On Tue, Mar 26, 2013 at 4:23 PM, Jeff Davis wrote: > > > >> > >> Patch attached. Only brief testing done, so I might have missed > >> something. I will look more closely later. > >> > > > >

Re: [HACKERS] WIP: index support for regexp search

On Wed, Apr 3, 2013 at 11:10 AM, Erikjan Rijkers wrote: > On Tue, April 2, 2013 23:54, Alexander Korotkov wrote: > > > [trgm-regexp-0.15.patch.gz] > > Yes, it does look good now; Attached a list of measurements. Most of the > searches that I put in > that test-program are now speeded up very much

Re: [HACKERS] WIP: index support for regexp search

can 21286.804 ms Not exactly negligible, and ideally those regressions would be removed but with the huge advantages for other cases I'd say it's worth it. hth, Erik Rijkers re-head-13-15-20130403-0708.txt.bz2 Description: BZip2 compressed data -- Sent via pgsql-hackers mailin

  1   2   >