Re: [HACKERS] Raise a WARNING if a REVOKE affects nothing?

That sounds like a good change to me. -- Darren Duncan Craig Ringer wrote: Hi all I'm seeing lots of confusion from people about why: REVOKE CONNECT ON DATABASE foo FROM someuser; doesn't stop them connecting. Users seem to struggle to understand that: - There's a default GRANT to public

[HACKERS] Raise a WARNING if a REVOKE affects nothing?

Hi all I'm seeing lots of confusion from people about why: REVOKE CONNECT ON DATABASE foo FROM someuser; doesn't stop them connecting. Users seem to struggle to understand that: - There's a default GRANT to public; and - REVOKE removes existing permissions, it doesn't add deny rules It'd

Re: [HACKERS] temporal support patch

On 08/21/2012 12:52 PM, Jeff Davis wrote: On Mon, 2012-08-20 at 16:32 -0700, Josh Berkus wrote: This is sounding like a completely runaway spec on what should be a simple feature. My feeling as well. However, we will eventually want to coalesce around some best practices and make it easy and r

Re: [HACKERS] NOT NULL constraints in foreign tables

On Mon, 2012-08-20 at 16:50 -0400, Robert Haas wrote: > #3 for foreign tables. I'm skeptical of that approach for two reasons: (1) It will be hard to inform users which constraints are enforced and which aren't. (2) It will be hard for users to understand the planner benefits or the consequences

Re: [HACKERS] temporal support patch

On 08/21/2012 12:52 PM, Jeff Davis wrote: On Mon, 2012-08-20 at 16:32 -0700, Josh Berkus wrote: This is sounding like a completely runaway spec on what should be a simple feature. My feeling as well. However, we will eventually want to coalesce around some best practices and make it easy and r

Re: [HACKERS] temporal support patch

On Mon, 2012-08-20 at 19:32 -0500, Kevin Grittner wrote: > Josh Berkus wrote: > > > This is sounding like a completely runaway spec on what should be > > a simple feature. > > I hate to contribute to scope creep (or in this case scope screaming > down the tracks at full steam), but I've been w

Re: [HACKERS] temporal support patch

On Mon, 2012-08-20 at 16:32 -0700, Josh Berkus wrote: > This is sounding like a completely runaway spec on what should be a > simple feature. My feeling as well. However, we will eventually want to coalesce around some best practices and make it easy and robust for "typical" cases. > Personally,

Re: [HACKERS] temporal support patch

On Mon, 2012-08-20 at 19:17 -0400, David Johnston wrote: > Ideally the decision of whether to do so could be a client decision. Not > storing intra-transaction changes is easier than storing all changes. At > worse you could stage up all changed then simply fail to store all > intermediate result

Re: [HACKERS] temporal support patch

On Mon, 2012-08-20 at 17:04 -0400, Robert Haas wrote: > On Sun, Aug 19, 2012 at 6:28 PM, Jeff Davis wrote: > >> The other issue is how to handle multiple changes of the same record > >> within the transaction. Should they be stored or not? > > > > In a typical audit log, I don't see any reason to.

Re: [HACKERS] PATCH: psql boolean display

On Mon, Aug 20, 2012 at 7:19 PM, Tom Lane wrote: > "Kevin Grittner" writes: >> The type itself does output true/false; it's just psql that uses >> t/f. > > No, 't'/'f' is what boolout() returns. The 'true'/'false' results from > casting bool to text are intentionally different --- IIRC, Peter E.

[HACKERS] TODO

I found this in https://wiki.postgresql.org/wiki/Todo : Improve ability to display optimizer analysis using OPTIMIZER_DEBUG What does this actually mean? Add GUC switch to enable optimizer debug on/off? More fancy/useful info should be printed? If so, what kind of information is required? --

Re: [HACKERS] sha1, sha2 functions into core?

On 08/20/2012 05:12 PM, Andrew Dunstan wrote: On 08/20/2012 07:08 PM, Tom Lane wrote: Moreover, as Josh just mentioned, anybody who thinks it might be insufficiently secure for their purposes has got plenty of alternatives available today (SSL certificates, PAM backed by whatever-you-want,

Re: [HACKERS] temporal support patch

Josh Berkus wrote: > This is sounding like a completely runaway spec on what should be > a simple feature. I hate to contribute to scope creep (or in this case scope screaming down the tracks at full steam), but I've been watching this with a queasy feeling about interaction with Serializable

Re: [HACKERS] sha1, sha2 functions into core?

On 08/20/2012 07:08 PM, Tom Lane wrote: Moreover, as Josh just mentioned, anybody who thinks it might be insufficiently secure for their purposes has got plenty of alternatives available today (SSL certificates, PAM backed by whatever-you-want, etc). Yeah, I think we need to emphasize this

Re: [HACKERS] Outdated Japanse developers FAQ

> On Tue, Aug 21, 2012 at 7:49 AM, Tatsuo Ishii wrote: >> Please let me know if this is not the right place to ask this kind of >> queston. >> >> PostgreSQL Developers FAQ in Japanese: >> >> http://wiki.postgresql.org/wiki/Developer_FAQ/ja >> >> looks pretty outdated. It was last updated on 7 Nove

Re: [HACKERS] Outdated Japanse developers FAQ

On Tue, Aug 21, 2012 at 7:49 AM, Tatsuo Ishii wrote: > Please let me know if this is not the right place to ask this kind of > queston. > > PostgreSQL Developers FAQ in Japanese: > > http://wiki.postgresql.org/wiki/Developer_FAQ/ja > > looks pretty outdated. It was last updated on 7 November 2010

Re: [HACKERS] temporal support patch

On 8/20/12 4:17 PM, David Johnston wrote: > The issue with adding the PostgreSQL role to the database in this way is > that you now can never delete that role or reassign it to another entity. I > guess with temporal you could do so and basically have the identity-role > relationship define over s

Re: [HACKERS] PATCH: psql boolean display

"Kevin Grittner" writes: > The type itself does output true/false; it's just psql that uses > t/f. No, 't'/'f' is what boolout() returns. The 'true'/'false' results from casting bool to text are intentionally different --- IIRC, Peter E. argued successfully that this cast behavior is required by

Re: [HACKERS] temporal support patch

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Monday, August 20, 2012 5:04 PM > To: Jeff Davis > Cc: Vlad Arkhipov; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] temporal support patch

Re: [HACKERS] PATCH: psql boolean display

> On Aug 20, 2012 6:28 PM, "Kevin Grittner" > wrote: >> >> Gurjeet Singh wrote: >> >> > On occasions I have wanted psql to emit the full 'True'/'False' >> > words instead of cryptic one-letter t/f, which can get lost on >> > long rows that get wrapped around on screen. Writing long-winded >> > CA

Re: [HACKERS] sha1, sha2 functions into core?

"Joshua D. Drake" writes: > On 08/20/2012 01:33 PM, Andrew Dunstan wrote: >> But there is absolutely no evidence that we are making it less useful. >> Postgres is designed top be extensible and we've just enhanced that. >> pgcrypto makes use of that. If we cen leverage that to make Postgres >> ava

Re: [HACKERS] PATCH: psql boolean display

On Aug 20, 2012 6:31 PM, "Thom Brown" wrote: > > On 20 August 2012 23:16, Phil Sorber wrote: > > > > On Aug 20, 2012 6:08 PM, "Thom Brown" wrote: > >> > >> On 20 August 2012 23:06, Phil Sorber wrote: > >> > > >> > On Aug 20, 2012 5:56 PM, "Thom Brown" wrote: > >> >> > >> >> On 20 August 2012 2

Re: [HACKERS] sha1, sha2 functions into core?

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > If the hacker has access to the salt, then it will only slow > him/her down somewhat because the search will be have to be > restarted for each password. This. Further, anyone using MD5 or SHA* or any hash function for any serious storage o

[HACKERS] Outdated Japanse developers FAQ

Please let me know if this is not the right place to ask this kind of queston. PostgreSQL Developers FAQ in Japanese: http://wiki.postgresql.org/wiki/Developer_FAQ/ja looks pretty outdated. It was last updated on 7 November 2010 (English FAQ was last updated on 27 September 2011). Even it says P

Re: [HACKERS] Large number of open(2) calls with bulk INSERT into empty table

Robert Haas writes: > On Mon, Aug 20, 2012 at 4:27 PM, Tom Lane wrote: >> Surely we could just prevent creation of the FSM until the table has >> reached at least, say, 10 blocks. >> >> Any threshold beyond one block would mean potential space wastage, >> but it's hard to get excited about that

Re: [HACKERS] PATCH: psql boolean display

On Aug 20, 2012 6:28 PM, "Kevin Grittner" wrote: > > Gurjeet Singh wrote: > > > On occasions I have wanted psql to emit the full 'True'/'False' > > words instead of cryptic one-letter t/f, which can get lost on > > long rows that get wrapped around on screen. Writing long-winded > > CASE expressi

Re: [HACKERS] PATCH: psql boolean display

On 20 August 2012 23:16, Phil Sorber wrote: > > On Aug 20, 2012 6:08 PM, "Thom Brown" wrote: >> >> On 20 August 2012 23:06, Phil Sorber wrote: >> > >> > On Aug 20, 2012 5:56 PM, "Thom Brown" wrote: >> >> >> >> On 20 August 2012 22:31, Phil Sorber wrote: >> >> > On Aug 20, 2012 5:19 PM, "Phil S

Re: [HACKERS] PATCH: psql boolean display

Gurjeet Singh wrote: > On occasions I have wanted psql to emit the full 'True'/'False' > words instead of cryptic one-letter t/f, which can get lost on > long rows that get wrapped around on screen. Writing long-winded > CASE expressions to get the effect is too much for small ad-hoc > queries.

Re: [HACKERS] PATCH: psql boolean display

On Aug 20, 2012 6:08 PM, "Thom Brown" wrote: > > On 20 August 2012 23:06, Phil Sorber wrote: > > > > On Aug 20, 2012 5:56 PM, "Thom Brown" wrote: > >> > >> On 20 August 2012 22:31, Phil Sorber wrote: > >> > On Aug 20, 2012 5:19 PM, "Phil Sorber" wrote: > >> >> > >> >> On Aug 20, 2012 5:11 PM,

Re: [HACKERS] PATCH: psql boolean display

On Mon, Aug 20, 2012 at 5:54 PM, Thom Brown wrote: > On 20 August 2012 22:10, Pavel Stehule wrote: > > 2012/8/20 Robert Haas : > >> On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber wrote: > >>> I am providing a patch to allow you to change the output of a boolean > >>> value in psql much like you

Re: [HACKERS] PATCH: psql boolean display

On 20 August 2012 23:06, Phil Sorber wrote: > > On Aug 20, 2012 5:56 PM, "Thom Brown" wrote: >> >> On 20 August 2012 22:31, Phil Sorber wrote: >> > On Aug 20, 2012 5:19 PM, "Phil Sorber" wrote: >> >> >> >> On Aug 20, 2012 5:11 PM, "Pavel Stehule" >> >> wrote: >> >> > >> >> > 2012/8/20 Robert H

Re: [HACKERS] PATCH: psql boolean display

On Aug 20, 2012 5:56 PM, "Thom Brown" wrote: > > On 20 August 2012 22:31, Phil Sorber wrote: > > On Aug 20, 2012 5:19 PM, "Phil Sorber" wrote: > >> > >> On Aug 20, 2012 5:11 PM, "Pavel Stehule" wrote: > >> > > >> > 2012/8/20 Robert Haas : > >> > > On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber

Re: [HACKERS] PATCH: psql boolean display

2012/8/20 Thom Brown : > On 20 August 2012 22:10, Pavel Stehule wrote: >> 2012/8/20 Robert Haas : >>> On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber wrote: I am providing a patch to allow you to change the output of a boolean value in psql much like you can do with NULL. A client request

Re: [HACKERS] PATCH: psql boolean display

On 20 August 2012 22:31, Phil Sorber wrote: > On Aug 20, 2012 5:19 PM, "Phil Sorber" wrote: >> >> On Aug 20, 2012 5:11 PM, "Pavel Stehule" wrote: >> > >> > 2012/8/20 Robert Haas : >> > > On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber wrote: >> > >> I am providing a patch to allow you to change t

Re: [HACKERS] PATCH: psql boolean display

On 20 August 2012 22:10, Pavel Stehule wrote: > 2012/8/20 Robert Haas : >> On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber wrote: >>> I am providing a patch to allow you to change the output of a boolean >>> value in psql much like you can do with NULL. A client requested this >>> feature and we th

Re: [HACKERS] PATCH: psql boolean display

On Aug 20, 2012 5:19 PM, "Phil Sorber" wrote: > > On Aug 20, 2012 5:11 PM, "Pavel Stehule" wrote: > > > > 2012/8/20 Robert Haas : > > > On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber wrote: > > >> I am providing a patch to allow you to change the output of a boolean > > >> value in psql much like

Re: [HACKERS] PATCH: psql boolean display

On Aug 20, 2012 5:11 PM, "Pavel Stehule" wrote: > > 2012/8/20 Robert Haas : > > On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber wrote: > >> I am providing a patch to allow you to change the output of a boolean > >> value in psql much like you can do with NULL. A client requested this > >> feature a

Re: [HACKERS] PATCH: psql boolean display

2012/8/20 Robert Haas : > On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber wrote: >> I am providing a patch to allow you to change the output of a boolean >> value in psql much like you can do with NULL. A client requested this >> feature and we thought it may appeal to someone else in the community.

Re: [HACKERS] temporal support patch

On Sun, Aug 19, 2012 at 6:28 PM, Jeff Davis wrote: >> The other issue is how to handle multiple changes of the same record >> within the transaction. Should they be stored or not? > > In a typical audit log, I don't see any reason to. The internals of a > transaction should be implementation detai

Re: [HACKERS] sha1, sha2 functions into core?

On 20 August 2012 21:26, Joshua D. Drake wrote: > > On 08/20/2012 01:21 PM, Josh Berkus wrote: >> >> >> >>> I don't think US export regulations are the only issue. Some other >>> countries (mostly the usual suspects) forbid the use of crypto software. >>> If we build more crypto functions into the

Re: [HACKERS] sha1, sha2 functions into core?

On 08/20/2012 01:33 PM, Andrew Dunstan wrote: But there is absolutely no evidence that we are making it less useful. Postgres is designed top be extensible and we've just enhanced that. pgcrypto makes use of that. If we cen leverage that to make Postgres available to more people then why would

Re: [HACKERS] NOT NULL constraints in foreign tables

On Mon, Aug 20, 2012 at 3:56 PM, Jeff Davis wrote: > On Fri, 2012-08-17 at 15:44 -0400, Robert Haas wrote: >> On Fri, Aug 17, 2012 at 2:58 PM, Alvaro Herrera >> wrote: >> > I mean, what are NOT NULL in foreign tables for? Are they harmed or >> > helped by having pg_constraint rows? >> >> As I've

Re: [HACKERS] Large number of open(2) calls with bulk INSERT into empty table

On Mon, Aug 20, 2012 at 4:27 PM, Tom Lane wrote: > Robert Haas writes: On the other hand, the problem of the FSM taking up 24kB for an 8kB table seems clearly worth fixing, but I don't think I have the cycles for it at present. Maybe a TODO is in order. > >> I certainly think that

Re: [HACKERS] "CLUSTER VERBOSE" tab completion

On Sun, Aug 19, 2012 at 4:55 PM, Jeff Janes wrote: > On Fri, Aug 17, 2012 at 7:18 PM, Jeff Janes wrote: >> tab completion will add "USING" after CLUSTER VERBOSE, as if VERBOSE >> were the name of a table. >> >> Instead of just making it not do the wrong thing, I tried to make it >> actually do th

Re: [HACKERS] sha1, sha2 functions into core?

On 08/20/2012 04:26 PM, Joshua D. Drake wrote: On 08/20/2012 01:21 PM, Josh Berkus wrote: I don't think US export regulations are the only issue. Some other countries (mostly the usual suspects) forbid the use of crypto software. If we build more crypto functions into the core we make it h

Re: [HACKERS] Tab completion for DROP CONSTRAINT

On Sun, Aug 19, 2012 at 4:43 PM, Jeff Janes wrote: > Interactively dropping primary key constraints has been annoying me. > > I believe this patch fixes that, hopefully for other kinds of > cataloged constraints as well. Committed, thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.co

Re: [HACKERS] Large number of open(2) calls with bulk INSERT into empty table

Robert Haas writes: >>> On the other hand, the problem of the FSM taking up 24kB for an 8kB >>> table seems clearly worth fixing, but I don't think I have the cycles >>> for it at present. Maybe a TODO is in order. > I certainly think that'd be worth a TODO. Whether the rest of this is > worth

Re: [HACKERS] sha1, sha2 functions into core?

On 08/20/2012 01:21 PM, Josh Berkus wrote: I don't think US export regulations are the only issue. Some other countries (mostly the usual suspects) forbid the use of crypto software. If we build more crypto functions into the core we make it harder to use Postgres legally in those places. I

Re: [HACKERS] sha1, sha2 functions into core?

> I don't think US export regulations are the only issue. Some other > countries (mostly the usual suspects) forbid the use of crypto software. > If we build more crypto functions into the core we make it harder to use > Postgres legally in those places. Again, that sounds like we need an actual

Re: [HACKERS] NOT NULL constraints in foreign tables

On Fri, 2012-08-17 at 15:44 -0400, Robert Haas wrote: > On Fri, Aug 17, 2012 at 2:58 PM, Alvaro Herrera > wrote: > > I mean, what are NOT NULL in foreign tables for? Are they harmed or > > helped by having pg_constraint rows? > > As I've mentioned when this has come up before, I think that > con

Re: [HACKERS] PATCH: psql boolean display

On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber wrote: > I am providing a patch to allow you to change the output of a boolean > value in psql much like you can do with NULL. A client requested this > feature and we thought it may appeal to someone else in the community. > > The patch includes updat

Re: [HACKERS] NOT NULL constraints in foreign tables

On Fri, Aug 17, 2012 at 4:08 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of vie ago 17 15:44:29 -0400 2012: >> On Fri, Aug 17, 2012 at 2:58 PM, Alvaro Herrera >> wrote: >> > I mean, what are NOT NULL in foreign tables for? Are they harmed or >> > helped by having pg_constrain

Re: [HACKERS] sha1, sha2 functions into core?

On 08/20/2012 03:10 PM, Josh Berkus wrote: On 8/15/12 6:48 AM, Tom Lane wrote: The argument against moving crypto code into core remains the same as it was, ie export regulations. I don't see that that situation has changed at all. Actually, I believe that it has, based on my experience getti

Re: [HACKERS] The pgrminclude problem

On Mon, Aug 20, 2012 at 12:03 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of lun ago 20 11:43:44 -0400 2012: >> I actually think we'd probably be better off running pgrminclude once >> per release cycle rather than any less often. When the number of >> changes gets into the hu

Re: [HACKERS] Large number of open(2) calls with bulk INSERT into empty table

On Thu, Aug 16, 2012 at 9:05 PM, Bruce Momjian wrote: > A TODO for this? You mean this part? >> On the other hand, the problem of the FSM taking up 24kB for an 8kB >> table seems clearly worth fixing, but I don't think I have the cycles >> for it at present. Maybe a TODO is in order. I certain

Re: [HACKERS] Timing overhead and Linux clock sources

On Thu, Aug 16, 2012 at 10:28 PM, Bruce Momjian wrote: > FYI, I am planning to go ahead and package this tool in /contrib for PG > 9.3. Isn't this exactly what we already did, in 9.2, in the form of contrib/pg_test_timing? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] sha1, sha2 functions into core?

On 8/15/12 6:48 AM, Tom Lane wrote: > The argument against moving crypto code into core remains the same as it > was, ie export regulations. I don't see that that situation has changed > at all. Actually, I believe that it has, based on my experience getting an export certificate for Sun Postgres

Re: [HACKERS] TRUE/FALSE vs true/false

On Thu, Aug 16, 2012 at 3:32 PM, Bruce Momjian wrote: > On Thu, Aug 16, 2012 at 02:21:12PM -0500, Kevin Grittner wrote: >> Bruce Momjian wrote: >> >> > So what do we want to do with this? I am a little concerned that >> > we are sacrificing code clarity for backpatching ease, but I don't >> > do

Re: [HACKERS] SERIAL columns in foreign tables

On Fri, Aug 17, 2012 at 10:53 AM, Alvaro Herrera wrote: > However I'm wondering if it'd be better to tweak the code to explicitely > check for SERIAL/BIGSERIAL instead of letting it error out in internal > conditions. The way it currently is, it seems a bit user-unfriendly to > me. I don't think

Re: [HACKERS] Rules and WITH and LATERAL

On Sun, Aug 19, 2012 at 12:06:30PM -0400, Tom Lane wrote: > While thinking about this I wondered whether it might be possible to > clean up the implementation of rules, and perhaps also get rid of some > of their semantic issues, by making the rule rewriter rely on WITH > and/or LATERAL, neither of

Re: [HACKERS] bug of pg_trgm?

Fujii Masao writes: > OK. Attached patch fixes the problem as you suggested, i.e., it backs up > "endword" if the second loop exits in an escape pair. Applied with a bit of further adjustment of the comments. Thanks! regards, tom lane -- Sent via pgsql-hackers mailing

Re: [HACKERS] gistchoose vs. bloat

On Mon, Aug 20, 2012 at 7:13 AM, Jeff Davis wrote: > I took a look at this patch. The surrounding code is pretty messy (not > necessarily because of your patch). A few comments would go a long way. > > The 'which_grow' array is initialized as it goes, first using pointer > notations ("*which_grow

Re: [HACKERS] Primary Key Constraint on inheritance table not getting route to child tables

On Mon, Aug 20, 2012 at 9:28 PM, Tom Lane wrote: > Rushabh Lathia writes: > > ALTER TABLE ADD Constraints PRIMARY KEY on inheritance table not getting > > route to child table. > > Right. > > > But when we do ALTER TABLE DROP Constraint on the same, it complains > about > > constraint does not e

Re: [HACKERS] Unexpected plperl difference between 8.4 and 9.1

Alvaro Herrera writes: > Excerpts from Alex Hunsaker's message of lun ago 20 12:03:11 -0400 2012: >> Hrm seems to work for me. What version of perl is this? >> $ perl -V >> Summary of my perl5 (revision 5 version 16 subversion 0) configuration: > I can reproduce the failure with 5.14.2 Smells li

Re: [HACKERS] The pgrminclude problem

Robert Haas writes: > On Thu, Aug 16, 2012 at 12:17 PM, Peter Geoghegan > wrote: >> Yeah. Even if this could be made to work well, we'd still have to do >> something like get an absolute consensus from all build farm animals, >> if we expected to have an absolutely trustworthy list. I don't thin

Re: [HACKERS] New WAL code dumps core trivially on replay of bad data

On 20.08.2012 18:25, Tom Lane wrote: Heikki Linnakangas writes: I was thinking that we might read gigabytes worth of bogus WAL into the memory buffer, if xl_tot_len is bogus and large, e.g 0x. But now that I look closer, the xlog record is validated after reading the first continuation

Re: [HACKERS] Unexpected plperl difference between 8.4 and 9.1

Excerpts from Alex Hunsaker's message of lun ago 20 12:03:11 -0400 2012: > On Sun, Aug 19, 2012 at 2:26 PM, Joel Jacobson wrote: > > > After upgrading from 8.4 to 9.1, one of my plperl functions stopped > > working properly. > > > > For some reason, when matching a string using a regex, the $1 va

Re: [HACKERS] bug of pg_trgm?

On Sat, Aug 11, 2012 at 8:15 AM, Tom Lane wrote: > Fujii Masao writes: >> No. ISTM that in_wildcard_meta must be reset before the second loop. >> Because the meaning of that flag in the first loop is different from that in >> the second loop. The former and the latter indicate whether the search

Re: [HACKERS] The pgrminclude problem

Excerpts from Robert Haas's message of lun ago 20 11:43:44 -0400 2012: > I actually think we'd probably be better off running pgrminclude once > per release cycle rather than any less often. When the number of > changes gets into the hundreds or thousands of lines it becomes much > more difficult

Re: [HACKERS] Unexpected plperl difference between 8.4 and 9.1

On Sun, Aug 19, 2012 at 2:26 PM, Joel Jacobson wrote: > After upgrading from 8.4 to 9.1, one of my plperl functions stopped > working properly. > > For some reason, when matching a string using a regex, the $1 variable > cannot be returned directly using return_next() but must be > set to a varia

Re: [HACKERS] Primary Key Constraint on inheritance table not getting route to child tables

Rushabh Lathia writes: > ALTER TABLE ADD Constraints PRIMARY KEY on inheritance table not getting > route to child table. Right. > But when we do ALTER TABLE DROP Constraint on the same, it complains about > constraint does not exists on child table. Works for me in HEAD. What version are you

Re: [HACKERS] The pgrminclude problem

On Thu, Aug 16, 2012 at 12:17 PM, Peter Geoghegan wrote: > On 16 August 2012 16:56, Bruce Momjian wrote: >> Good to know. We only use pgrminclude very five years or so, and Tom >> isn't even keen on that. > > Yeah. Even if this could be made to work well, we'd still have to do > something like ge

Re: [HACKERS] Primary Key Constraint on inheritance table not getting route to child tables

Excerpts from Rushabh Lathia's message of lun ago 20 02:50:52 -0400 2012: > Hi, > > ALTER TABLE ADD Constraints PRIMARY KEY on inheritance table not getting > route to child table. > > But when we do ALTER TABLE DROP Constraint on the same, it complains about > constraint does not > exists on chi

Re: [HACKERS] Avoiding repeated snapshot computation

On Thu, Aug 16, 2012 at 9:02 PM, Bruce Momjian wrote: > Did we ever make a decision on this patch? I committed it as 1fc3d18faa8f4476944bc6854be0f7f6adf4aec8. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] SP-GiST for ranges based on 2d-mapping and quad-tree

Jeff Davis writes: > On Sat, 2012-07-28 at 17:50 -0400, Tom Lane wrote: >> which would come >> back to bite us if we ever try to support index-only scans with SPGiST. > I'm confused: > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=92203624934095163f8b57b5b3d7bbd2645da2c8 Sorry, I

Re: [HACKERS] New WAL code dumps core trivially on replay of bad data

Heikki Linnakangas writes: > On 20.08.2012 17:04, Tom Lane wrote: >> Uh, no, you misread it. xl_tot_len is *zero* in this example. The >> problem is that RecordIsValid believes xl_len (and backup block size) >> even when it exceeds xl_tot_len. > Ah yes, I see that now. I think all we need then

Re: [HACKERS] New WAL code dumps core trivially on replay of bad data

On 20.08.2012 17:04, Tom Lane wrote: Heikki Linnakangas writes: On 18.08.2012 08:52, Amit kapila wrote: I think that missing check of total length has caused this problem. However now this check will be different. That check still exists, in ValidXLogRecordHeader(). However, we now allocat

[HACKERS] alter enum add value if not exists

Here is a patch for this feature, which should alleviate some of the woes caused by adding labels not being transactional (and thus not allowing for the catching of errors). (Also available on the add_enum_ine branch at ) cheers andrew *** a/doc/sr

Re: [HACKERS] New WAL code dumps core trivially on replay of bad data

On Monday, August 20, 2012 04:04:52 PM Tom Lane wrote: > Heikki Linnakangas writes: > > On 18.08.2012 08:52, Amit kapila wrote: > >> I think that missing check of total length has caused this problem. > >> However now this check will be different. > > > > That check still exists, in ValidXLogReco

Re: [HACKERS] New WAL code dumps core trivially on replay of bad data

Heikki Linnakangas writes: > On 18.08.2012 08:52, Amit kapila wrote: >> I think that missing check of total length has caused this problem. However >> now this check will be different. > That check still exists, in ValidXLogRecordHeader(). However, we now > allocate the buffer for the whole rec

Re: [HACKERS] enhanced error fields

Hello here is updated patch - merge comments, docs, formatting, some identifiers from Peter Geoghegan's patch Regards Pavel 2012/7/18 Pavel Stehule : > Hello > > * renamed erritem to err_generic_string > * fixed CSVlog generation > * new file /utils/error/relerror.c with axillary functions - >

Re: [HACKERS] State of the on-disk bitmap index

Am 20.08.2012 11:44, schrieb Daniel Bausch: > Actually, I was not involved in writing that paper. I want to use that > idea to show something different. I know of a follow up work by Golam > Rabilul Alam et al. that uses the query history and data mining on that > to optimize for the most common

Re: [HACKERS] State of the on-disk bitmap index

Am 20.08.2012 09:40, schrieb Albe Laurenz: > Daniel Bausch wrote: >> Hello Jonah, Simon, and the hackers, >> >> I am going to implement a simple kind of "encoded bitmap indexes" > (EBI). >> That is an index type where the bitmap columns may not only contain >> only a single '1' in the set of bits

Re: [HACKERS] [PATCH] Docs: Make notes on sequences and rollback more obvious

Trying again with the attachments; the archiver only seemed to see the first patch despite all three being attached. Including patches inline; if you want 'em prettier, see: https://github.com/ringerc/postgres/tree/sequence_documentation_fixes Subject: [PATCH 1/3] Make sure you can't read t

[HACKERS] Primary Key Constraint on inheritance table not getting route to child tables

Hi, ALTER TABLE ADD Constraints PRIMARY KEY on inheritance table not getting route to child table. But when we do ALTER TABLE DROP Constraint on the same, it complains about constraint does not exists on child table. Consider the following example psql=# CREATE TABLE measurement ( psql(# ci

Re: [HACKERS] State of the on-disk bitmap index

Daniel Bausch wrote: > Hello Jonah, Simon, and the hackers, > > I am going to implement a simple kind of "encoded bitmap indexes" (EBI). > That is an index type where the bitmap columns may not only contain > only a single '1' in the set of bits belonging to a tuple. Instead, an > additional map