Re: [HACKERS] pg_archivecleanup should remove WAL files also in pg_xlog?

On Mon, Dec 13, 2010 at 4:28 PM, Heikki Linnakangas wrote: > On 13.12.2010 08:44, Fujii Masao wrote: >> >> pg_archivecleanup removes unnecessary WAL files from the archive, but not >> from pg_xlog directory. So, after failover, those WAL files might >> exist in pg_xlog and be archived again later.

[HACKERS] hstores in pl/python

It would be cool to be able to transparently use hstores as Python dictionaries and vice versa. It would be easy enough with hstore as a core type, but with hstore as an addon it's not that easy. There was talk about including hstore in core, is there still chance for that to happen in 9.1? I'd li

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, 2010-12-12 at 19:07 -0500, Tom Lane wrote: > Robert Haas writes: > > ... On the > > other hand, there's clearly also a use case for this behavior. If a > > bulk load of prevalidated data forces an expensive revalidation of > > constraints that are already known to hold, there's a real ch

Re: [HACKERS] proposal : cross-column stats

> On Sun, Dec 12, 2010 at 9:16 PM, Tomas Vondra wrote: >> Dne 13.12.2010 03:00, Robert Haas napsal(a): >>> Well, the question is what data you are actually storing.  It's >>> appealing to store a measure of the extent to which a constraint on >>> column X constrains column Y, because you'd only ne

Re: [HACKERS] pg_archivecleanup should remove WAL files also in pg_xlog?

On 13.12.2010 08:44, Fujii Masao wrote: pg_archivecleanup removes unnecessary WAL files from the archive, but not from pg_xlog directory. So, after failover, those WAL files might exist in pg_xlog and be archived again later. A file that has already been archived successfully should not be arc

Re: [HACKERS] proposal: auxiliary functions for record type

2010/12/12 Florian Pflug : > On Dec12, 2010, at 00:19 , Pavel Stehule wrote: >> I prefer a table based >> solution, because I don't need a one "unnest", but other preferences >> are valid too. > That's fine with me. > >> I dissatisfied with your design of explicit target type >> via unused value.  

Re: [HACKERS] pg_archivecleanup should remove WAL files also in pg_xlog?

On Mon, Dec 13, 2010 at 3:44 PM, Fujii Masao wrote: > pg_archivecleanup removes unnecessary WAL files from the archive, but not > from pg_xlog directory. So, after failover, those WAL files might > exist in pg_xlog > and be archived again later. Re-archiving of unnecessary WAL files seems odd > to

[HACKERS] pg_archivecleanup should remove WAL files also in pg_xlog?

Hi, pg_archivecleanup removes unnecessary WAL files from the archive, but not from pg_xlog directory. So, after failover, those WAL files might exist in pg_xlog and be archived again later. Re-archiving of unnecessary WAL files seems odd to me. To avoid this problem, how about changing pg_archivec

Re: [HACKERS] SQL/MED - file_fdw

On Sat, Dec 11, 2010 at 05:30, Andrew Dunstan wrote: > On 12/04/2010 11:11 PM, Itagaki Takahiro wrote: >> One exports the copy functions from the core, and another >> implements file_fdw using the infrastructure. > > Who is actually going to do this split? I'm working for it :-) I extract those

Re: [HACKERS] unlogged tables

On Sun, Dec 12, 2010 at 7:33 PM, Robert Haas wrote: > On Sun, Dec 12, 2010 at 9:31 PM, Rob Wultsch wrote: >> On Fri, Dec 10, 2010 at 5:34 PM, Cédric Villemain >> wrote: >>> 2010/12/8 Kineticode Billing : On Dec 8, 2010, at 10:37 AM, Chris Browne wrote: > Other possibilities include

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, Dec 12, 2010 at 7:24 PM, Andrew Dunstan wrote: > In fact it's possible now to disable FK enforcement, by disabling the > triggers. It's definitely a footgun though. Just the other day I was asked > how data violating the constraint could have got into the table, and caused > some surprise

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

On Sun, Dec 12, 2010 at 8:16 AM, Tom Lane wrote: > > What are the values of _S_IREAD and _S_IWRITE, anyway? I'm still > > wondering how come the previous coding with hardwired constants > > behaved correctly. > > Still curious about this. > > FWIW, _S_IREAD and _S_IWRITE are defined by Visual St

[HACKERS] pg_is_in_recovery=1

Hi All, When pg_is_in_recovery in the table changes to zero(status change)?? At the time when recovery stops? If switch over has to be done then, after receivibg the signal and telling the postgres to run the startup process (got_SIGHUP = true), shall we have to stop replication or wait for the r

Re: [HACKERS] SQL/MED - core functionality

On Sun, 12 Dec 2010 23:47:53 +0200 Peter Eisentraut wrote: > On ons, 2010-12-01 at 12:30 +0900, Hitoshi Harada wrote: > > From a user's view, this is very long way to see a simplest foreign > > table. I know it is based on the standard, but I really want a > > shortcut. Especially, I don't underst

[HACKERS] rest of works for security providers in v9.1

I'd like to see opinions what facilities should be developed to the current v9.1 development cycle. We have integrated some of facilities to support a starter- version of SE-PostgreSQL. It allows to hook controls on DML permission checks and assign security labels of client and database obejcts ei

Re: [HACKERS] Instrument checkpoint sync calls

On Sun, Dec 5, 2010 at 4:23 PM, Greg Smith wrote: > Jeff Janes wrote: >> >> I've attached a tiny patch to apply over yours, to deal with this and >> with the case where no files are synced. >> > > Thanks for that.  That obvious error eluded me because in most of the patch > update testing I was do

Re: [HACKERS] proposal : cross-column stats

>> The proposed solution is based on contingency tables, built for selected >> groups of columns (not for each possible group). And the contingency >> table gives you the ability to estimate the probabilities needed to >> compute the selectivity. Or am I missing something? > > Well, I'm not real fa

Re: [HACKERS] PS display and standby query conflict

On Sat, Dec 11, 2010 at 11:28 PM, Simon Riggs wrote: >> This problem happens because ResolveRecoveryConflictWithVirtualXIDs >> resets PS display for each read-only transactions that recovery >> waits for. Why do we need to reset that each time even though >> the conflict has not been resolved yet?

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

Peter Geoghegan wrote: > If we followed this behaviour, we wouldn't "let people just > arbitrarily claim" that a referential condition exists - rather, > we'd let them assert that it /ought/ to exist, and that it will be > maintained going forward, and give them the option of verifying > that as

Re: [HACKERS] BufFreelistLock

On Dec 10, 2010, at 10:49 AM, Tom Lane wrote: > Alvaro Herrera writes: >> Excerpts from Jeff Janes's message of vie dic 10 12:24:34 -0300 2010: >>> As far as I can tell, bgwriter never adds things to the freelist. >>> That is only done at start up, and when a relation or a database is >>> dropped.

Re: [HACKERS] libpq changes for synchronous replication

On Sat, Dec 11, 2010 at 11:37 PM, Robert Haas wrote: > Committed with just a few changes to the documentation. Thanks a lot! Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] unlogged tables

On Sun, Dec 12, 2010 at 9:31 PM, Rob Wultsch wrote: > On Fri, Dec 10, 2010 at 5:34 PM, Cédric Villemain > wrote: >> 2010/12/8 Kineticode Billing : >>> On Dec 8, 2010, at 10:37 AM, Chris Browne wrote: >>> Other possibilities include TRANSIENT, EPHEMERAL, TRANSIENT, TENUOUS. >>> >>> EVANESCENT

Re: [HACKERS] unlogged tables

On Fri, Dec 10, 2010 at 5:34 PM, Cédric Villemain wrote: > 2010/12/8 Kineticode Billing : >> On Dec 8, 2010, at 10:37 AM, Chris Browne wrote: >> >>> Other possibilities include TRANSIENT, EPHEMERAL, TRANSIENT, TENUOUS. >> >> EVANESCENT. > > UNSAFE ? > MyISAM -- Rob Wultsch wult...@gmail.com

Re: [HACKERS] proposal : cross-column stats

On Sun, Dec 12, 2010 at 9:16 PM, Tomas Vondra wrote: > Dne 13.12.2010 03:00, Robert Haas napsal(a): >> Well, the question is what data you are actually storing.  It's >> appealing to store a measure of the extent to which a constraint on >> column X constrains column Y, because you'd only need to

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

I wouldn't like to comment on whether or not Simon has correctly interpreted the words of the SQL standards committee, because standards committees sometimes word things in an intentionally ambiguous way to placate different interests, and because it seems fairly inconsequential in this case. IMHO

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On 12/12/2010 08:27 PM, Rob Wultsch wrote: MySQL does in fact have this feature and it is used by mysqldump. This feature is very useful. The trouble is that FK's have more than one use. In particular, they have a documentary use that's used by tools that analyze databases, as well as by

Re: [HACKERS] proposal : cross-column stats

Dne 13.12.2010 03:00, Robert Haas napsal(a): > Well, the question is what data you are actually storing. It's > appealing to store a measure of the extent to which a constraint on > column X constrains column Y, because you'd only need to store > O(ncolumns^2) values, which would be reasonably com

Re: [HACKERS] proposal : cross-column stats

> P(A|B) = P(A and B) / P(B). Well, until this point we've discussed failure cases involving 'AND' conditions. What about 'OR' conditions? I think the current optimizer computes the selectivity as 's1+s2 - s1*s2' (at least that's what I found in backend/optimizer/path/clausesel.c:630). Sometimes

Re: [HACKERS] proposal : cross-column stats

On Sun, Dec 12, 2010 at 8:46 PM, Tomas Vondra wrote: > Dne 13.12.2010 01:05, Robert Haas napsal(a): >> This is a good idea, but I guess the question is what you do next.  If >> you know that the "applicability" is 100%, you can disregard the >> restriction clause on the implied column.  And if it

Re: [HACKERS] proposal : cross-column stats

Dne 13.12.2010 01:05, Robert Haas napsal(a): > This is a good idea, but I guess the question is what you do next. If > you know that the "applicability" is 100%, you can disregard the > restriction clause on the implied column. And if it has no > implicatory power, then you just do what we do now

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, Dec 12, 2010 at 4:49 PM, Robert Haas wrote: > On Sun, Dec 12, 2010 at 6:20 PM, Tom Lane wrote: >> Simon Riggs writes: >>> On Sun, 2010-12-12 at 17:57 -0500, Tom Lane wrote: Huh?  It allows you to postpone the check until commit.  That's far from not enforcing it. >> >>> This cl

Re: [HACKERS] Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE

On Dec13, 2010, at 00:16 , Robert Haas wrote: > And in fact it strikes me that we might not have much choice about how > to fix this. I think we are not going to retroactively change the > behavior of ALTER DATABASE .. SET ROLE in a released version, but yet > we do, I think, want to make pg_upgra

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, Dec 12, 2010 at 7:07 PM, Tom Lane wrote: > Robert Haas writes: >> ...  On the >> other hand, there's clearly also a use case for this behavior.  If a >> bulk load of prevalidated data forces an expensive revalidation of >> constraints that are already known to hold, there's a real chance

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

Robert Haas writes: > ... On the > other hand, there's clearly also a use case for this behavior. If a > bulk load of prevalidated data forces an expensive revalidation of > constraints that are already known to hold, there's a real chance the > DBA will be backed into a corner where he simply h

Re: [HACKERS] proposal : cross-column stats

On Sun, Dec 12, 2010 at 9:43 AM, Heikki Linnakangas wrote: > The way I think of that problem is that once you know the postcode, knowing > the city name doesn't add any information. The postcode implies the city > name. So the selectivity for "postcode = ? AND city = ?" should be the > selectivity

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, Dec 12, 2010 at 6:20 PM, Tom Lane wrote: > Simon Riggs writes: >> On Sun, 2010-12-12 at 17:57 -0500, Tom Lane wrote: >>> Huh?  It allows you to postpone the check until commit.  That's far from >>> not enforcing it. > >> This clearly implies that un-enforced constraints are not checked at

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

Simon Riggs writes: > On Sun, 2010-12-12 at 17:57 -0500, Tom Lane wrote: >> Huh? It allows you to postpone the check until commit. That's far from >> not enforcing it. > This clearly implies that un-enforced constraints are not checked at > commit. [ shrug... ] I can't argue with you about wh

Re: [HACKERS] Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE

On Sun, Dec 12, 2010 at 11:01 AM, Tom Lane wrote: > This is about like arguing that pg_dump and pg_upgrade should still work > after you've done "delete from pg_proc;".  Superusers are assumed to > know what they're doing and not break fundamental operations. No, it isn't like that at all. You'v

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Peter Eisentraut writes: > On mån, 2010-10-18 at 15:50 -0400, Tom Lane wrote: >> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar' >> the creation and properties of /foo/bar/PG_9.0_201004261 ought to be >> handled *exactly* the way that the -D target directory of initdb is.

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, 2010-12-12 at 17:57 -0500, Tom Lane wrote: > Simon Riggs writes: > > The new SQL Standard (SQL:2011) contains this: > > "Table constraints are either enforced or not enforced. Domain > > constraints and assertions are always enforced.", 4.17.2 > > > The SQL Standard allows you to turn the

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

Simon Riggs writes: > The new SQL Standard (SQL:2011) contains this: > "Table constraints are either enforced or not enforced. Domain > constraints and assertions are always enforced.", 4.17.2 > The SQL Standard allows you to turn the checking on and off for CHECK > constraints, UNIQUE constraint

[HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

The new SQL Standard (SQL:2011) contains this: "Table constraints are either enforced or not enforced. Domain constraints and assertions are always enforced.", 4.17.2 The SQL Standard allows you to turn the checking on and off for CHECK constraints, UNIQUE constraints and FOREIGN KEYS. Which of

Re: [HACKERS] Per-column collation

On mån, 2010-12-06 at 21:26 +0200, Peter Eisentraut wrote: > > > * contrib/citext raises an encoding error when COLLATE is specified > > even if it is the collation as same as the database default. > > We might need some special treatment for C locale. > > =# SHOW lc_collate; ==> C > > =# SELECT

Re: [HACKERS] Per-column collation

On tis, 2010-12-07 at 11:46 +0900, Itagaki Takahiro wrote: > On Sun, Dec 5, 2010 at 01:04, Peter Eisentraut wrote: > > Here is an updated patch to address the issues discussed during this > > commitfest. > > I found another issue in the patch; ILIKE in WHERE clause doesn't work. > It was surprisi

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On mån, 2010-10-18 at 15:50 -0400, Tom Lane wrote: > Yeah. We have gotten complaints in the past from people who tried to > specify a mount point as a tablespace, and it failed because of > lost+found or the mount dir being root-owned. We've told them to make > a subdirectory, but that always see

Re: [HACKERS] Wildcard search support for pg_trgm

On Mon, Dec 13, 2010 at 12:14 AM, Dimitri Fontaine wrote: > How different (and better) is it from wildspeed? > The general advantage is possibility of usage wildcard search and trigram similarity search using the same index. I expect that GIN trigram index is slightly less space demanding, but sl

Re: [HACKERS] Extensions, patch v17

On Dec 12, 2010, at 12:50 PM, Dimitri Fontaine wrote: > The only item with still some work to be done on it is the regression > tests support: we're not aiming to full coverage is my understanding, > and installing contribs goes a long way towards testing extensions. Do > we want more? If so, plea

Re: [HACKERS] SQL/MED - core functionality

On ons, 2010-12-01 at 12:30 +0900, Hitoshi Harada wrote: > I've tried SQL/MED with postgresql_fdw last night, and found myself > confusing the long setup procedure. A simplest way to use it AFAIK is: > > 1.CREATE FOREIGN DATA WRAPPER ... (or run install sql script) > 2.CREATE SERVER ... FOREIGN DA

Re: [HACKERS] Wildcard search support for pg_trgm

Alexander Korotkov writes: > Here is first version of patch, which enable index support of wildcard > search in pg_trgm contrib module. How different (and better) is it from wildspeed? http://www.sai.msu.su/~megera/wiki/wildspeed Regards, -- Dimitri Fontaine http://2ndQuadrant.fr Postgre

Re: [HACKERS] unlogged tables

Cédric Villemain writes: > 2010/12/8 Kineticode Billing : >> On Dec 8, 2010, at 10:37 AM, Chris Browne wrote: >> >>> Other possibilities include TRANSIENT, EPHEMERAL, TRANSIENT, TENUOUS. I kind of like TRANSIENT, but that's only because it's a property I've been working with in some other systems

Re: [HACKERS] [COMMITTERS] pgsql: Make S_IRGRP etc available in mingw builds as well as MSVC.

Magnus Hagander writes: > On Sun, Dec 12, 2010 at 19:54, Tom Lane wrote: >> It's a fair question.  We could clean up some of these messy ifdefs >> if we dropped support for that combination.  I assume that an MSVC-built >> libpq.dll would still work for Borland users, no? > The dynamic one, yes.

Re: [HACKERS] [COMMITTERS] pgsql: Make S_IRGRP etc available in mingw builds as well as MSVC.

On Sun, Dec 12, 2010 at 19:54, Tom Lane wrote: > Andrew Dunstan writes: >> On 12/12/2010 01:43 PM, Tom Lane wrote: >>> (Hm, I wonder whether BCC defines them either...) > >> Is anyone building the client stuff with BCC any more? I don't recall >> having heard of anyone doing so for quite some yea

Re: [HACKERS] [COMMITTERS] pgsql: Make S_IRGRP etc available in mingw builds as well as MSVC.

Andrew Dunstan writes: > On 12/12/2010 01:43 PM, Tom Lane wrote: >> (Hm, I wonder whether BCC defines them either...) > Is anyone building the client stuff with BCC any more? I don't recall > having heard of anyone doing so for quite some years. It's a fair question. We could clean up some of

[HACKERS] Re: [COMMITTERS] pgsql: Make S_IRGRP etc available in mingw builds as well as MSVC.

On 12/12/2010 01:43 PM, Tom Lane wrote: Make S_IRGRP etc available in mingw builds as well as MSVC. (Hm, I wonder whether BCC defines them either...) Is anyone building the client stuff with BCC any more? I don't recall having heard of anyone doing so for quite some years. cheers andre

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

Andrew Dunstan writes: > On 12/12/2010 11:16 AM, Tom Lane wrote: >> I put in #define's for these, and it seems to have fixed the MSVC >> buildfarm members, but cygwin is still broken. How come ... doesn't >> that port use port/win32.h? > ITYM Mingw. And yes, it does use port/win32.h; narwhal's l

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

On 12/12/2010 11:16 AM, Tom Lane wrote: I put in #define's for these, and it seems to have fixed the MSVC buildfarm members, but cygwin is still broken. How come ... doesn't that port use port/win32.h? ITYM Mingw. And yes, it does use port/win32.h; narwhal's log says: config.status: li

Re: [HACKERS] Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE

On Dec12, 2010, at 17:01 , Tom Lane wrote: > Florian Pflug writes: >> pg_upgrade aborted during the step "Adding support functions to new cluster" >> with "ERROR: permission denied for language c" error. Unfortunately, the >> log didn't include the name of the database where the error occurred,

Re: [HACKERS] function attributes

Andrew Dunstan writes: > On 12/12/2010 10:43 AM, Tom Lane wrote: >>> At the moment the behaviour is triggered by a custom setting >>> (plperl.pass_binary_bytea), but this isn't really satisfactory. >> I do not want to go there. > But the real issue is that we have no way of specifying properties

Re: [HACKERS] proposal : cross-column stats

Dne 12.12.2010 17:33, Florian Pflug napsal(a): > On Dec12, 2010, at 15:43 , Heikki Linnakangas wrote: >> The way I think of that problem is that once you know the postcode, knowing >> the city name doesn't add any information. The postcode implies the city >> name. So the selectivity for "postcod

Re: [HACKERS] function attributes

On 12/12/2010 10:43 AM, Tom Lane wrote: At the moment the behaviour is triggered by a custom setting (plperl.pass_binary_bytea), but this isn't really satisfactory. We could turn it on permanently, but that would break a lot of legacy code. What we really need is a way of marking a function

Re: [HACKERS] proposal : cross-column stats

On Dec12, 2010, at 15:43 , Heikki Linnakangas wrote: > The way I think of that problem is that once you know the postcode, knowing > the city name doesn't add any information. The postcode implies the city > name. So the selectivity for "postcode = ? AND city = ?" should be the > selectivity of

Re: [HACKERS] function attributes

On 12/12/2010 10:43 AM, Tom Lane wrote: Tim Bunce seemed to think that this particular problem might be solvable in a completely transparent way, by having byteas convert into Perl objects that have a hook for producing a backwards-compatible text translation. Have you looked into that idea?

Re: [HACKERS] proposal : cross-column stats

Dne 12.12.2010 15:43, Heikki Linnakangas napsal(a): >> The classic failure case has always been: postcodes and city names. >> Strongly correlated, but in a way that the computer can't easily see. > > Yeah, and that's actually analogous to the example I used in my > presentation. > > The way I thi

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

I wrote: > Magnus Hagander writes: >> On Sat, Dec 11, 2010 at 18:46, Tom Lane wrote: >>> I think we can just #define the other cases as zeroes.  I'm not sure why >>> you think that's an issue for open --- the privileges don't exist. >> Hmm. I was/am worried about any case that specifies *just* o

Re: [HACKERS] Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE

Florian Pflug writes: > pg_upgrade aborted during the step "Adding support functions to new cluster" > with "ERROR: permission denied for language c" error. Unfortunately, the log > didn't include the name of the database where the error occurred, so it took > me a while to figure out that the

Re: [HACKERS] proposal : cross-column stats

Hi! Dne 12.12.2010 15:17, Martijn van Oosterhout napsal(a): >> Lets talk about one special case - I'll explain how the proposed >> solution works, and then I'll explain how to make it more general, what >> improvements are possible, what issues are there. Anyway this is by no >> means a perfect or

Re: [HACKERS] function attributes

Andrew Dunstan writes: > Yesterday I did a bit of work on allowing bytea values to be passed into > and out of plperl in binary format, effectively removing the need to > escape and de-escape them. (The work can be seen on he plperlargs branch > of my development repo at >

Re: [HACKERS] proposal : cross-column stats

On 12.12.2010 15:17, Martijn van Oosterhout wrote: On Sun, Dec 12, 2010 at 03:58:49AM +0100, Tomas Vondra wrote: Very cool that you're working on this. +1 Lets talk about one special case - I'll explain how the proposed solution works, and then I'll explain how to make it more general, what i

Re: [HACKERS] Extensions, patch v16

Hi there, it's clear we need versions, probably, major.minor would be enough. The problem I see is how to keep .so in sync with .sql ? Should we store .sql in database ? Also, we need permissions for extension, since we have open/closed extensions. Oleg On Sat, 11 Dec 2010, David E. Wheeler

Re: [HACKERS] proposal : cross-column stats

On Sun, Dec 12, 2010 at 03:58:49AM +0100, Tomas Vondra wrote: > Hi everyone, > > one of the ssesion I've attended on PgDay last week was Heikki's session > about statistics in PostgreSQL. One of the issues he mentioned (and one > I regularly run into) is the absence of cross-column stats. When the

Re: [HACKERS] proposal: auxiliary functions for record type

2010/12/12 Florian Pflug : > On Dec12, 2010, at 00:19 , Pavel Stehule wrote: >> I prefer a table based >> solution, because I don't need a one "unnest", but other preferences >> are valid too. > That's fine with me. > >> I dissatisfied with your design of explicit target type >> via unused value.  

Re: [HACKERS] Wildcard search support for pg_trgm

I found another problem. GIN index suffers from "GIN indexes do not support whole-index scans" when no trigram can be extracted from pattern. With best regards, Alexander Korotkov.

[HACKERS] Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records

On Sat, 2010-12-11 at 22:03 +0100, Heikki Linnakangas wrote: > (Moving to pgsql-hackers) > > On 10.12.2010 20:21, Tom Lane wrote: > > Simon Riggs writes: > >> Reduce spurious Hot Standby conflicts from never-visible records. > >> Hot Standby conflicts only with tuples that were visible at > >> so

[HACKERS] Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE

Hi I've just ran into a problem while upgrading from 8.4 to 9.0. pg_upgrade aborted during the step "Adding support functions to new cluster" with "ERROR: permission denied for language c" error. Unfortunately, the log didn't include the name of the database where the error occurred, so it too

Re: [HACKERS] proposal: auxiliary functions for record type

On Dec12, 2010, at 00:19 , Pavel Stehule wrote: > I prefer a table based > solution, because I don't need a one "unnest", but other preferences > are valid too. That's fine with me. > I dissatisfied with your design of explicit target type > via unused value. I think, so we are not a infrastructu