Re: [HACKERS] Transaction-scope advisory locks

On Thu, Feb 10, 2011 at 08:36, Marko Tiikkaja wrote: >> One issue might be in pg_locks > Robert suggested not doing this for 9.1, and I don't have anything against > that. Agreed. > Updated patch attached. Looks good to commit. I note a few minor issues for committer: * Functions listed in "Ta

Re: [HACKERS] Varchar and binary protocol

On Thu, Feb 10, 2011 at 2:56 AM, Radosław Smogura wrote: > Merlin Moncure Thursday 10 February 2011 08:48:26 >> On Sat, Feb 5, 2011 at 4:59 PM, Radosław Smogura >> >> Since there is basically zero difference in how *varchar* is handled >> in the database for the text or binary protocols (AFAIK, t

Re: [HACKERS] patches that could use additional reviewers

[Cc: trimmed] On Wed, Feb 09, 2011 at 01:45:11PM -0500, Robert Haas wrote: > A few other ones that could use more reviewers include: > key locks I'll take a look at this one. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.

[HACKERS] Re: [COMMITTERS] pgsql: Update docs on building for Windows to accomodate current realit

On 02/10/2011 01:04 AM, Gurjeet Singh wrote: This commit refers to www.mingw64.org which does not exist. Oops. URL (and name) fixed. thanks. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Add support for logging the current role

On Mon, Feb 7, 2011 at 04:10, Stephen Frost wrote: > Yeah, doesn't seem to work for me (missing '/bin/collateindex.pl', > apparently..). You might need "yum install openjade stylesheets" or similar packages and re-"configure". > Ok, I've cleaned up that part of the documentation to be a table in

Re: [HACKERS] Range Types - efficiency

* Chris Browne: > The RangeType-based equivalent is the following: > > rangetest@localhost-> explain analyze select * from some_data where > '[2010-01-01,2010-02-01)'::daterange @> whensit; >QUERY PLAN >

Re: [HACKERS] SSI patch version 14

On 09.02.2011 17:58, Kevin Grittner wrote: Dan Ports wrote: I think for SerializableXidHash we should probably just initially allocate it at its maximum size. Then it'll match the PredXact list which is allocated in full upfront, and there's no risk of being able to allocate a transaction but

Re: [HACKERS] pl/python explicit subtransactions

On 10/02/11 01:26, Steve Singer wrote: > On 11-02-09 05:22 PM, Peter Eisentraut wrote: >> On tis, 2011-02-08 at 00:32 -0500, Steve Singer wrote: >> Is it necessarily a good idea that an explicit subtransaction disables >> the implicit sub-subtransactions? It might be conceivable that you'd >> stil

Re: [HACKERS] SSI patch version 14

On 02/10/2011 05:09 AM, Heikki Linnakangas wrote: On 09.02.2011 17:58, Kevin Grittner wrote: Dan Ports wrote: I think for SerializableXidHash we should probably just initially allocate it at its maximum size. Then it'll match the PredXact list which is allocated in full upfront, and there's

[HACKERS] psql patch: tab-complete :variables also at buffer start

Currently, tab-completing :variable names in psql does not work at the beginning of the line. Fix this by moving the code block before the "empty buffer" case. (I have several "sql macros" in my .psqlrc like :relsize that prints table sizes in a nicely formatted way, being able to type : would be

Re: [HACKERS] Re: [COMMITTERS] pgsql: Update docs on building for Windows to accomodate current realit

On Thu, Feb 10, 2011 at 07:04, Gurjeet Singh wrote: > This commit refers to www.mingw64.org which does not exist. Andrew fixed this alreayd. > Also, clicking on the gitweb link below (from GMail), opens the browser > window with an address where ';' are replaced with %3B , which leads to 404 > -

Re: [HACKERS] [COMMITTERS] pgsql: Remove more SGML tabs.

On ons, 2011-02-09 at 08:00 -0800, David Fetter wrote: > On Wed, Feb 09, 2011 at 01:17:06PM +, Bruce Momjian wrote: > > Remove more SGML tabs. > > Perhaps we should see about putting something in .git/hooks/pre-commit > so people can focus on more substantive matters. > > Is there some kind o

Re: [HACKERS] Move WAL warning

On Thu, Feb 10, 2011 at 03:20, Fujii Masao wrote: > On Wed, Feb 9, 2011 at 7:02 PM, Magnus Hagander wrote: >> On Thu, Feb 3, 2011 at 11:19, Magnus Hagander wrote: >>> On Wed, Feb 2, 2011 at 18:00, Magnus Hagander wrote: On Wed, Feb 2, 2011 at 17:43, Heikki Linnakangas wrote: > On

Re: [HACKERS] Add support for logging the current role

On Thu, Feb 10, 2011 at 06:56:15PM +0900, Itagaki Takahiro wrote: > On Mon, Feb 7, 2011 at 04:10, Stephen Frost wrote: > >> I agree that it's logically good design, but we could not accept it > >> as long as it breaks tools in the real world... > > If it does, I think it's pretty clear that those

[HACKERS] xlog functions for pg_basebackup

In cleaning up the streaming part of pg_basebackup, I came across this gem I copied from elsewherE: /* * We have to use postgres.h not postgres_fe.h here, because there's so much * backend-only stuff in the XLOG include files we need. But we need a * frontend-ish environment otherwise. Hence

Re: [HACKERS] Add support for logging the current role

On Thu, Feb 10, 2011 at 6:27 AM, Noah Misch wrote: > FWIW, a 330 byte boot_val doesn't seem like a big deal to me.  If it were over > _POSIX2_LINE_MAX (2048), that might be another matter. I don't think it's entirely stupid to worry about this completely screwing up the output of "SHOW ALL" on pe

Re: [HACKERS] PostgreSQL FDW update

On Tue, Feb 8, 2011 at 3:52 AM, Heikki Linnakangas wrote: > I needed something to test the FDW API patch with, and didn't want to get > involved in the COPY API changes, and also wanted to have something that > needs real connection management and can push down quals. So I updated the > postgresql

Re: [HACKERS] psql patch: tab-complete :variables also at buffer start

On Thu, Feb 10, 2011 at 19:37, Christoph Berg wrote: > Currently, tab-completing :variable names in psql does not work at the > beginning of the line. Fix this by moving the code block before the > "empty buffer" case. Seems reasonable to me. -- Itagaki Takahiro -- Sent via pgsql-hackers mail

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote: > On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin wrote: >> >> What was actually broken in encode_array_literal support of composite types >> (it converted perl hashes to the literal composite-type constants, expanding >> nested arrays along the way

Re: [HACKERS] Re: [COMMITTERS] pgsql: Update docs on building for Windows to accomodate current realit

On Thu, Feb 10, 2011 at 5:46 AM, Magnus Hagander wrote: > On Thu, Feb 10, 2011 at 07:04, Gurjeet Singh wrote: >> This commit refers to www.mingw64.org which does not exist. > > Andrew fixed this alreayd. > >> Also, clicking on the gitweb link below (from GMail), opens the browser >> window with a

Re: [HACKERS] Re: [COMMITTERS] pgsql: Update docs on building for Windows to accomodate current realit

On Thu, Feb 10, 2011 at 14:22, Robert Haas wrote: > On Thu, Feb 10, 2011 at 5:46 AM, Magnus Hagander wrote: >> On Thu, Feb 10, 2011 at 07:04, Gurjeet Singh wrote: >>> This commit refers to www.mingw64.org which does not exist. >> >> Andrew fixed this alreayd. >> >>> Also, clicking on the gitweb

Re: [HACKERS] keeping a timestamp of the last stats reset (for a db, table and function)

On Sun, Feb 6, 2011 at 08:17, Greg Smith wrote: > Tomas Vondra wrote: >> >> Because when I create a database, the field is >> NULL - that's true. But once I connect to the database, the stats are >> updated and the field is set (thanks to the logic in pgstat.c). >> > > OK--so it does what I was ho

Re: [HACKERS] Re: [COMMITTERS] pgsql: Update docs on building for Windows to accomodate current realit

On Thu, Feb 10, 2011 at 8:38 AM, Magnus Hagander wrote: > On Thu, Feb 10, 2011 at 14:22, Robert Haas wrote: >> On Thu, Feb 10, 2011 at 5:46 AM, Magnus Hagander wrote: >>> On Thu, Feb 10, 2011 at 07:04, Gurjeet Singh >>> wrote: This commit refers to www.mingw64.org which does not exist. >>

Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting

On Tue, Feb 8, 2011 at 05:24, Robert Haas wrote: > On Wed, Jan 19, 2011 at 1:01 AM, Fujii Masao wrote: >> On Thu, Jan 13, 2011 at 9:08 PM, Fujii Masao wrote: >>> I did s/failover/promote. Here is the updated patch. >> >> I rebased the patch to current git master. > > This patch looks fine to me.

Re: [HACKERS] [COMMITTERS] pgsql: Remove more SGML tabs.

Excerpts from Peter Eisentraut's message of jue feb 10 07:58:16 -0300 2011: > One thing I was thinking of was that we could add a global make > maintainer-check target (a name I picked up from other projects) which > would run various source code sanity checks. Besides the SGML tabs > issue, my f

Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting

On Thu, Feb 10, 2011 at 15:25, Magnus Hagander wrote: > On Tue, Feb 8, 2011 at 05:24, Robert Haas wrote: >> On Wed, Jan 19, 2011 at 1:01 AM, Fujii Masao wrote: >>> On Thu, Jan 13, 2011 at 9:08 PM, Fujii Masao wrote: I did s/failover/promote. Here is the updated patch. >>> >>> I rebased the

Re: [HACKERS] Range Types (catversion.h)

On Wed, February 9, 2011 09:35, Jeff Davis wrote: > Updated patch. > Thanks! I just wanted to mention that this latest patch doesn't quite apply as-is, because of catversion changes. I've removed the change to catversion.h (18 lines, starting at 4985) from the patch file; then it applies clean

Re: [HACKERS] postponing some large patches to 9.2

On Tue, Feb 8, 2011 at 7:58 PM, Jeff Davis wrote: > On the flip side, if we don't provide review to WIP patches during the > 3rd commitfest, how do we expect to get anything close to committable on > the 1st commitfest of the next cycle? I'm not sure exactly what you're going for here, because I

Re: [HACKERS] log_hostname and pg_stat_activity

On Tue, Feb 1, 2011 at 1:33 PM, Robert Haas wrote: > On Tue, Feb 1, 2011 at 1:09 PM, Peter Eisentraut wrote: >> On tis, 2011-01-18 at 19:24 -0500, Steve Singer wrote: >>> However if I connect with a line in pg_hba that matches on an IP >>> network then my client_hostname is always null unless log

Re: [HACKERS] patches that could use additional reviewers

On Wed, Feb 9, 2011 at 1:45 PM, Robert Haas wrote: > A few other ones that could use more reviewers include: I've just corrected the status of a few patches in the CommitFest application. In particular, I set the following back to Needs Review. SQL/MED - postgresql_fdw Self-tuning checkpoint sy

Re: [HACKERS] pg_dump directory archive format / parallel pg_dump

On Tue, Feb 8, 2011 at 10:54 PM, Joachim Wieland wrote: > On Tue, Feb 8, 2011 at 8:31 PM, Itagaki Takahiro > wrote: >> On Tue, Feb 8, 2011 at 13:34, Robert Haas wrote: >>> So how close are we to having a committable version of this?  Should >>> we push this out to 9.2? >> >> I think so. The feat

Re: [HACKERS] log_hostname and pg_stat_activity

On 11-02-10 10:13 AM, Robert Haas wrote: On Tue, Feb 1, 2011 at 1:33 PM, Robert Haas wrote: On Tue, Feb 1, 2011 at 1:09 PM, Peter Eisentraut wrote: On tis, 2011-01-18 at 19:24 -0500, Steve Singer wrote: However if I connect with a line in pg_hba that matches on an IP network then my client_h

[HACKERS] Adding new variables into GUC

Hi, I am an MSc student in the department of Informatics and Telecommunications of the University of Athens and as part of my thesis I am examining a new path/plan cost model for DB optimizers. I have successfully changed the optimizer of PostgreSQL in order to implement this model, but I

Re: [HACKERS] log_hostname and pg_stat_activity

On Thu, Feb 10, 2011 at 10:22 AM, Steve Singer wrote: > On 11-02-10 10:13 AM, Robert Haas wrote: >> >> On Tue, Feb 1, 2011 at 1:33 PM, Robert Haas  wrote: >>> >>> On Tue, Feb 1, 2011 at 1:09 PM, Peter Eisentraut  wrote: On tis, 2011-01-18 at 19:24 -0500, Steve Singer wrote: > > H

Re: [HACKERS] log_hostname and pg_stat_activity

On 11-02-10 10:32 AM, Robert Haas wrote: I was assuming those changes were sufficiently trivial that they could be made at commit-time, especially if Peter is committing it himself. Of course if he'd like a re-review, he can always post an updated patch, but I just thought that was overly pedant

Re: [HACKERS] Extensions versus pg_upgrade

Robert Haas writes: > On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote: >> In contrast, ALTER EXTENSION ADD doesn't presuppose that you couldn't >> add the object to multiple extensions; and it has a natural inverse, >> ALTER EXTENSION DROP.  I am not necessarily suggesting that we will ever >> all

Re: [HACKERS] Extensions versus pg_upgrade

On Thu, Feb 10, 2011 at 10:41 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote: >>> In contrast, ALTER EXTENSION ADD doesn't presuppose that you couldn't >>> add the object to multiple extensions; and it has a natural inverse, >>> ALTER EXTENSION DROP.

Re: [HACKERS] Extensions versus pg_upgrade

Tom Lane writes: > Actually, it occurs to me that the need for ALTER EXTENSION DROP could > be upon us sooner than we think. The cases where an extension upgrade > script would need that are > (1) you want to remove some deprecated piece of the extension's API; > (2) you want to remove some no-lo

Re: [HACKERS] Extensions versus pg_upgrade

Dimitri Fontaine writes: > Tom Lane writes: >> Actually, it occurs to me that the need for ALTER EXTENSION DROP could >> be upon us sooner than we think. The cases where an extension upgrade >> script would need that are >> (1) you want to remove some deprecated piece of the extension's API; >>

Re: [HACKERS] Adding new variables into GUC

=?ISO-8859-7?B?yNzt7/Ig0OHw4fDd9PHv9Q==?= writes: > I am an MSc student in the department of Informatics and > Telecommunications of the University of Athens and as part of my > thesis I am examining a new path/plan cost model for DB optimizers. I > have successfully changed the optimizer of

Re: [HACKERS] Extensions versus pg_upgrade

Tom Lane writes: > That would be rejected because you're not allowed to drop an individual > member object of an extension. (And no, I don't want to have a kluge in > dependency.c that makes that test work differently when > creating_extension.) Fair enough, all the more as soon as we have ALTER

Re: [HACKERS] Range Types (catversion.h)

"Erik Rijkers" writes: > On Wed, February 9, 2011 09:35, Jeff Davis wrote: >> Updated patch. > I just wanted to mention that this latest patch doesn't quite apply as-is, > because of catversion changes. Just a note: standard practice is for submitted patches to *not* touch catversion.h. The co

Re: [HACKERS] Range Types (catversion.h)

On Thu, 2011-02-10 at 12:04 -0500, Tom Lane wrote: > "Erik Rijkers" writes: > > On Wed, February 9, 2011 09:35, Jeff Davis wrote: > >> Updated patch. > > > I just wanted to mention that this latest patch doesn't quite apply as-is, > > because of catversion changes. > > Just a note: standard pra

Re: [HACKERS] Range Types (catversion.h)

On tor, 2011-02-10 at 09:28 -0800, Jeff Davis wrote: > I originally put it there so that I wouldn't mix up data directories > with a patch I'm reviewing, but I agree that it seems easier this way. FWIW, I disagree with Tom and do recommend putting the catversion change in the patch. -- Sent via

Re: [HACKERS] Range Type constructors

On Wed, Feb 9, 2011 at 2:09 AM, Jeff Davis wrote: > That's how arrays do it: there's a special Expr node that represents an > array expression. Maybe the same thing could be used for range types, > but I fear that there may be some grammar conflicts. I doubt we'd want > to fully reserve the keywor

Re: [HACKERS] Range Types (catversion.h)

On Thu, 2011-02-10 at 15:38 +0100, Erik Rijkers wrote: > I've removed the change to catversion.h (18 lines, starting at 4985) from the > patch file; then it > applies cleanly. I should mention that the last patch changed the representation to be more compact. So, if you have any existing test dat

Re: [HACKERS] Range Types (catversion.h)

On 10.02.2011 20:01, Peter Eisentraut wrote: On tor, 2011-02-10 at 09:28 -0800, Jeff Davis wrote: I originally put it there so that I wouldn't mix up data directories with a patch I'm reviewing, but I agree that it seems easier this way. FWIW, I disagree with Tom and do recommend putting the c

Re: [HACKERS] postponing some large patches to 9.2

On Thu, 2011-02-10 at 09:46 -0500, Robert Haas wrote: > On Tue, Feb 8, 2011 at 7:58 PM, Jeff Davis wrote: > > On the flip side, if we don't provide review to WIP patches during the > > 3rd commitfest, how do we expect to get anything close to committable on > > the 1st commitfest of the next cycle

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

I spent some time reviewing this thread. I think the major point that's not received adequate discussion is this: the design assumes that there's just one "current version" of any extension, and that's not good enough. David Fetter was trying to make that point upthread but didn't seem to convince

Re: [HACKERS] Range Types (catversion.h)

On Thu, Feb 10, 2011 at 1:23 PM, Heikki Linnakangas wrote: > On 10.02.2011 20:01, Peter Eisentraut wrote: >> >> On tor, 2011-02-10 at 09:28 -0800, Jeff Davis wrote: >>> >>> I originally put it there so that I wouldn't mix up data directories >>> with a patch I'm reviewing, but I agree that it seem

Re: [HACKERS] [COMMITTERS] pgsql: Remove more SGML tabs.

On Thu, Feb 10, 2011 at 12:58:16PM +0200, Peter Eisentraut wrote: > On ons, 2011-02-09 at 08:00 -0800, David Fetter wrote: > > On Wed, Feb 09, 2011 at 01:17:06PM +, Bruce Momjian wrote: > > > Remove more SGML tabs. > > > > Perhaps we should see about putting something in .git/hooks/pre-commit

Re: [HACKERS] Range Type constructors

On Thu, 2011-02-10 at 13:07 -0500, Robert Haas wrote: > According to our documentation[1], RANGE is reserved in SQL:2008 and > SQL:2003, which makes it more imaginable to reserve it than it would > be otherwise. Oh, interesting. > I believe that in a previous email you mentioned that > you were h

Re: [HACKERS] Range Type constructors

On Thu, Feb 10, 2011 at 1:41 PM, Jeff Davis wrote: > This might solve the constructor problem nicely if we could do things > like: >  RANGE[10,20) > But I have a feeling that will either cause a bizarre problem with the > grammar, or someone will think it's not very SQL-like. I think won't cause

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 10, 2011, at 10:26 AM, Tom Lane wrote: > 1. Choose the newest available version. > 2. Let the control file specify which version is the default. > I think I prefer #2 because it avoids needing a rule for comparing > version identifiers, and it caters to the possibility that the

Re: [HACKERS] Adding new variables into GUC

> You basically need the variable, the entry in the appropriate array in > guc.c, and some documentation (at least if you'd like anyone else to > ever use the code). Try looking at some past patches that added GUCs > similar to yours. For completeness, it would also be good to add rows to the pg

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 10, 2011 at 1:26 PM, Tom Lane wrote: > requires, relocatable and schema: These are problematic, because it's not > out of the question that someone might want to change these properties > from one version to another.  But as things are currently set up, we must > know these things befo

Re: [HACKERS] Adding new variables into GUC

2011/2/10 Josh Berkus : > >> You basically need the variable, the entry in the appropriate array in >> guc.c, and some documentation (at least if you'd like anyone else to >> ever use the code).  Try looking at some past patches that added GUCs >> similar to yours. > > For completeness, it would al

Re: [HACKERS] Sync Rep for 2011CF1

On 08.02.2011 20:53, Robert Haas wrote: That having been said, there is at least one part of this patch which looks to be in pretty good shape and seems independently useful regardless of what happens to the rest of it, and that is the code that sends replies from the standby back to the primary.

Re: [HACKERS] Range Type constructors

> This might solve the constructor problem nicely if we could do things > like: > RANGE[10,20) > But I have a feeling that will either cause a bizarre problem with the > grammar, or someone will think it's not very SQL-like. It will certainly mess up syntax highlighting and matching bracket dete

Re: [HACKERS] [COMMITTERS] pgsql: Remove more SGML tabs.

On tor, 2011-02-10 at 10:40 -0800, David Fetter wrote: > I think all such checks belong in .git/hooks/pre-commit, and need to > be as cross-platform as needed for committers. Would a *n*x-based > version do for a start? I think as a matter of principle, the only things that belongs into git hooks

Re: [HACKERS] Range Type constructors

Florian Pflug writes: >> This might solve the constructor problem nicely if we could do things >> like: >> RANGE[10,20) >> But I have a feeling that will either cause a bizarre problem with the >> grammar, or someone will think it's not very SQL-like. > It will certainly mess up syntax highlighti

Re: [HACKERS] pl/python custom exceptions for SPI

On sön, 2011-02-06 at 20:44 +0100, Jan Urbański wrote: > On 27/01/11 23:24, Jan Urbański wrote: > > On 11/01/11 12:20, Jan Urbański wrote: > >> On 11/01/11 01:27, Tom Lane wrote: > >>> Hannu Krosing writes: > On 10.1.2011 17:20, Jan Urbański wrote: > > I changed that patch to use Perl ins

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

"David E. Wheeler" writes: > +1. I assume there will be some way to build versioned shared object > libraries too, then? I'm not really addressing that in this proposal. You could imagine supporting all the extension versions in one .so, or you could have one per version (meaning the upgrade sc

Re: [HACKERS] Adding new variables into GUC

Josh Berkus writes: >> You basically need the variable, the entry in the appropriate array in >> guc.c, and some documentation (at least if you'd like anyone else to >> ever use the code). Try looking at some past patches that added GUCs >> similar to yours. > For completeness, it would also be

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 10, 2011, at 11:31 AM, Tom Lane wrote: > I'm not really addressing that in this proposal. You could imagine > supporting all the extension versions in one .so, or you could have one > per version (meaning the upgrade scripts would have to CREATE OR REPLACE > all the C functions to re-point

Re: [HACKERS] Range Type constructors

On Feb 10, 2011, at 10:41 AM, Jeff Davis wrote: > This might solve the constructor problem nicely if we could do things > like: > RANGE[10,20) > But I have a feeling that will either cause a bizarre problem with the > grammar, or someone will think it's not very SQL-like. I like it a lot better

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On 02/10/2011 08:15 AM, Alexey Klyukin wrote: On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote: On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin wrote: What was actually broken in encode_array_literal support of composite types (it converted perl hashes to the literal composite-type constants, e

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: > On Thu, Feb 10, 2011 at 1:26 PM, Tom Lane wrote: >> requires, relocatable and schema: These are problematic, because it's not >> out of the question that someone might want to change these properties >> from one version to another.  But as things are currently set up, we mus

Re: [HACKERS] Range Type constructors

On Feb 10, 2011, at 11:21 AM, Tom Lane wrote: >> It will certainly mess up syntax highlighting and matching bracket detection >> in pretty much all text editors... > > Yeah. It's a cute-looking notation but surely it will cause many more > problems than it's worth. I agree with Robert's suggest

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

"David E. Wheeler" writes: > On Feb 10, 2011, at 11:31 AM, Tom Lane wrote: >> I don't see how that affects my point? You can spell "1.0" as "0.1" >> and "1.1" as "0.2" if you like that kind of numbering, but I don't >> see that that has any real impact. At the end of the day an author is >> goin

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 10, 2011 at 2:42 PM, Tom Lane wrote: > General opinion around Red Hat is relocatable RPMs don't work.  But > pushing a set of functions from one schema to another is a very much > narrower problem than what an RPM has to deal with, so I'm not convinced > that the analogy holds. > > Now

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane wrote: > "David E. Wheeler" writes: >> On Feb 10, 2011, at 11:31 AM, Tom Lane wrote: >>> I don't see how that affects my point?  You can spell "1.0" as "0.1" >>> and "1.1" as "0.2" if you like that kind of numbering, but I don't >>> see that that has any

Re: [HACKERS] pl/python custom exceptions for SPI

On 10/02/11 20:24, Peter Eisentraut wrote: > On sön, 2011-02-06 at 20:44 +0100, Jan Urbański wrote: >> On 27/01/11 23:24, Jan Urbański wrote: >>> On 11/01/11 12:20, Jan Urbański wrote: On 11/01/11 01:27, Tom Lane wrote: > Hannu Krosing writes: >> On 10.1.2011 17:20, Jan Urbański wrote

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: >> Now, if you want to argue that moving an extension after the fact (ALTER >> EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't >> argue very hard.  Do you want to propose ripping that out?  But >> relocating at first install doesn't seem horrible. Either an

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 10, 2011 at 3:33 PM, Dimitri Fontaine wrote: > Robert Haas writes: >>> Now, if you want to argue that moving an extension after the fact (ALTER >>> EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't >>> argue very hard.  Do you want to propose ripping that out?  But >>

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 10, 2011, at 12:02 PM, Tom Lane wrote: > Oh, I see, you're just saying that it's not unlikely somebody could find > himself with dozens of minor releases all being supported. Yeah, he'd > then really need to provide shortcut upgrade scripts, and > building/maintaining those would be a pain

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 10, 2011, at 12:07 PM, Robert Haas wrote: > You don't need them to be sortable. You just need them to be > comparable, and equality seems like a plenty good enough comparison > rule. You can compute the shortest chain of upgrade scripts that can > take you from the current version to the

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: > On Thu, Feb 10, 2011 at 2:42 PM, Tom Lane wrote: >> Now, if you want to argue that moving an extension after the fact (ALTER >> EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't >> argue very hard.  Do you want to propose ripping that out?  But >> relocating

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 10, 2011 at 3:46 PM, David E. Wheeler wrote: > On Feb 10, 2011, at 12:07 PM, Robert Haas wrote: > >> You don't need them to be sortable.  You just need them to be >> comparable, and equality seems like a plenty good enough comparison >> rule.  You can compute the shortest chain of upgr

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: > On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane wrote: >> The design as I sketched it didn't need to make any assumptions at all >> about the meaning of the version identifiers.  But if you were willing >> to assume that the identifiers are comparable/sortable by some rule, > You

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Hi, Tom Lane writes: > I spent some time reviewing this thread. I think the major point that's Thanks for doing that, we badly needed someone without an horse in this race to do that and finish the design. > So I believe that it'd be a good idea if it were possible for an extension > author to

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: > No, you have to get *those other module authors* to make *their* > extensions not relocatable so that you can depend on them. Just tell me exactly in which world an extension's author is setting up the dependencies in the 'required' property and yet fails to realise that tho

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 10, 2011 at 3:58 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane wrote: >>> The design as I sketched it didn't need to make any assumptions at all >>> about the meaning of the version identifiers.  But if you were willing >>> to assume that the

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Tom Lane writes: > I don't think it's appropriate to hold extensions to a > higher standard than we do loose objects --- especially when it takes > superuser privileges to break things by moving an extension but not to > break them by moving loose objects. FWIW, +1. Regards, -- Dimitri Fontaine

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 10, 2011 at 4:14 PM, Dimitri Fontaine wrote: > Robert Haas writes: >> No, you have to get *those other module authors* to make *their* >> extensions not relocatable so that you can depend on them. > > Just tell me exactly in which world an extension's author is setting up > the depend

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: > On Thu, Feb 10, 2011 at 3:58 PM, Tom Lane wrote: >> Hmm.  The problem with that is that once there are large numbers of >> intermediate versions, the number of potential paths grows >> exponentially. > It's certainly not exponential i.e. O(2^n) or something of that form. >

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 10, 2011 at 3:52 PM, Tom Lane wrote: >> The real issue is what happens when you want to install >> extension A, which depends on extensions B, C, and D, and B, C, and D >> are all in non-standard locations.  Does that have any chance of >> working under the system we're proposing? > >

Re: [HACKERS] Revised patches to add table function support to PL/Tcl (TODO item)

On 02/08/2011 08:37 PM, Andrew Dunstan wrote: On 02/07/2011 11:30 PM, Robert Haas wrote: On Tue, Dec 28, 2010 at 9:23 PM, Karl Lehenbauer wrote: On Dec 28, 2010, at 7:29 PM, Tom Lane wrote: This patch appears to be changing a whole lot of stuff that in fact pg_indent has never changed, s

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 10, 2011, at 1:22 PM, Tom Lane wrote: > Well, okay, let's go with that plan then. If we don't need to assume > anything more than equality of version names being meaningful, I think > chaining update scripts automatically should solve most of the > complaints here. People who really want

Re: [HACKERS] pl/python custom exceptions for SPI

On 11-02-10 03:13 PM, Jan Urbański wrote: On 10/02/11 20:24, Peter Eisentraut wrote: Here is the rest of my review. Submission Review --- Patch applies cleanly. Documentation is still outstanding but Jan has promised it soon. Usability Review --- We don't have

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On Feb 10, 2011, at 9:44 PM, Andrew Dunstan wrote: > > > On 02/10/2011 08:15 AM, Alexey Klyukin wrote: >> On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote: >> >>> On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin >>> wrote: What was actually broken in encode_array_literal support of composite

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: > Well, the difference is that loose objects are just on my system, > whereas extensions are supposed to work on anybody's system. I'm not > clear that it's possible to write an extension that depends on a > relocatable extension in a sensible way. If it is, objection > withd

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

"David E. Wheeler" writes: > Yes, I think that this is a great solution. I only have to create on > upgrade script for each release, and I don't have to worry about > concatenating anything or be required to change my versioning > algorithm. You still have to make sure that the C code remains com

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: > On Thu, Feb 10, 2011 at 3:52 PM, Tom Lane wrote: >> Again, it's not really any different from the case where the dependent >> objects are "loose" rather than members of an extension. > Well, the difference is that loose objects are just on my system, > whereas extensions ar

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 10, 2011, at 1:38 PM, Tom Lane wrote: > I don't deny that there are risks here. But I think the value of being > able to move an extension when it is safe outweighs the difficulty that > sometimes it isn't safe. I think we can leave making it safer as a > topic for future investigation. >

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 10, 2011 at 9:38 PM, Tom Lane wrote: >> Well, the difference is that loose objects are just on my system, >> whereas extensions are supposed to work on anybody's system.  I'm not >> clear that it's possible to write an extension that depends on a >> relocatable extension in a sensible

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Dimitri Fontaine writes: > "David E. Wheeler" writes: >> Yes, I think that this is a great solution. I only have to create on >> upgrade script for each release, and I don't have to worry about >> concatenating anything or be required to change my versioning >> algorithm. > You still have to mak

Re: [HACKERS] [COMMITTERS] pgsql: Remove more SGML tabs.

On Thu, Feb 10, 2011 at 09:16:09PM +0200, Peter Eisentraut wrote: > On tor, 2011-02-10 at 10:40 -0800, David Fetter wrote: > > I think all such checks belong in .git/hooks/pre-commit, and need > > to be as cross-platform as needed for committers. Would a > > *n*x-based version do for a start? > >

Re: [HACKERS] [COMMITTERS] pgsql: Remove more SGML tabs.

On Thu, Feb 10, 2011 at 11:29:43AM -0300, Alvaro Herrera wrote: > Excerpts from Peter Eisentraut's message of jue feb 10 07:58:16 -0300 2011: > > > One thing I was thinking of was that we could add a global make > > maintainer-check target (a name I picked up from other projects) > > which would r

Re: [HACKERS] SPI_exec doesn't return proc context (on 9.1)

Excerpts from Pavel Stehule's message of sáb ene 29 16:56:40 -0300 2011: > 2011/1/29 Tom Lane : > > The less crocky way to do that is to use SPI_palloc() for something that > > should be allocated in the outer context. > > I understand. Is there some way, where I can use a cstring_to_text > funct

  1   2   >