Re: [HACKERS] Review: Patch FORCE_NULL option for copy COPY in CSV mode

On 01/29/2014 10:59 AM, Ian Lawrence Barwick wrote: 2014/1/29 Ian Lawrence Barwick : 2014-01-29 Andrew Dunstan : On 01/28/2014 05:55 AM, Ian Lawrence Barwick wrote: Hi Payal Many thanks for the review, and my apologies for not getting back to you earlier. Updated version of the patch

Re: [HACKERS] Securing "make check" (CVE-2014-0067)

On 03/02/2014 01:27 PM, Tom Lane wrote: Also, to what extent does any of this affect buildfarm animals? Whatever we do for "make check" will presumably make those tests safe for them, but how are the postmasters they test under "make installcheck" set up? Nothing special. "bin/initdb" -

Re: [HACKERS] Review: Patch FORCE_NULL option for copy COPY in CSV mode

On 03/02/2014 10:06 PM, Ian Lawrence Barwick wrote: 2014-03-02 8:26 GMT+09:00 Andrew Dunstan : On 01/29/2014 10:59 AM, Ian Lawrence Barwick wrote: 2014/1/29 Ian Lawrence Barwick : 2014-01-29 Andrew Dunstan : On 01/28/2014 05:55 AM, Ian Lawrence Barwick wrote: Hi Payal Many thanks for the

Re: [HACKERS] Securing "make check" (CVE-2014-0067)

On 03/03/2014 02:00 AM, Tom Lane wrote: Josh Berkus writes: The only way I can see this being of real use to an attacker is if they could use this exploit to create a wormed version of PostgresQL on the target build system. Is that possible? It's theoretically possible, since having broken i

Re: [HACKERS] jsonb and nested hstore

On 03/03/2014 07:50 PM, Peter Geoghegan wrote: On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan wrote: In order to make a rational decision to do the work incrementally, we need to know what we're putting off until 9.5. AFAICT, we have these operator classes that work fine with jsonb for the p

Re: [HACKERS] jsonb and nested hstore

On 03/03/2014 10:39 PM, Peter Geoghegan wrote: On Mon, Mar 3, 2014 at 6:54 PM, Andrew Dunstan wrote: My aim for 9.4, given constraints of both the development cycle and my time budget, has been to get jsonb to a point where it has equivalent functionality to json, so that nobody is forced to

Re: [HACKERS] jsonb and nested hstore

On 03/03/2014 11:20 PM, Peter Geoghegan wrote: On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus wrote: Also, please recognize that the current implementation was what we collectively decided on three months ago, and what Andrew worked pretty hard to implement based on that collective decision. So

Re: [HACKERS] plpgsql.warn_shadow

On 03/04/2014 11:23 AM, Joel Jacobson wrote: I understand that from a technical perspective, the mandatory BEGIN...END you always need in a PL/pgSQL function, is a new block, and the variables declared are perhaps technically in a new block, at a deeper level than the IN/OUT variables. But I wo

Re: [HACKERS] plpgsql.warn_shadow

On 03/04/2014 03:40 PM, Joel Jacobson wrote: On Tue, Mar 4, 2014 at 8:04 PM, Andrew Dunstan wrote: Lots of code quite correctly relies on this, including some I have written. I really cannot see when it would be a good coding practise to do so, there must be something I don't understa

Re: [HACKERS] Review: Patch FORCE_NULL option for copy COPY in CSV mode

On 03/03/2014 06:48 AM, Michael Paquier wrote: On Mon, Mar 3, 2014 at 1:13 PM, Andrew Dunstan wrote: That difference actually made the file_fdw regression results plain wrong, in my view, in that they expected a quoted empty string to be turned to null even when the null string was something

Re: [HACKERS] Review: Patch FORCE_NULL option for copy COPY in CSV mode

On 03/05/2014 09:11 AM, Michael Paquier wrote: After testing this feature, I noticed that FORCE_NULL and FORCE_NOT_NULL can both be specified with COPY on the same column. This does not seem correct. The attached patch adds some more error handling, and a regression test case for that. Stric

Re: [HACKERS] jsonb and nested hstore

On 03/05/2014 09:39 AM, Bruce Momjian wrote: So, I am going to ask a back-track question and ask why we can't move hstore into core. Is this a problem with the oids of the hstore data type and functions? Is this a pg_upgrade-only problem? Can this be fixed? Yes, pg_upgrade is the problem,

Re: [HACKERS] jsonb and nested hstore

On 03/05/2014 10:24 AM, Tom Lane wrote: Also, there might be other cases besides arrays where we've embedded type OIDs in on-disk data; anyone remember? Don't we do that in composites too? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postg

Re: [HACKERS] jsonb and nested hstore

On 03/05/2014 10:30 AM, Tom Lane wrote: Merlin Moncure writes: On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane wrote: Also, there might be other cases besides arrays where we've embedded type OIDs in on-disk data; anyone remember? composite types. But that's only the composite type's own OID, no?

Re: [HACKERS] jsonb and nested hstore

On 03/05/2014 11:34 AM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Just out of curiosity, exactly what features are missing from jsonb today that are available with hstore? How long would it take to copy-and-paste all that code, if someone were to decide to do the work instead

Re: [HACKERS] jsonb and nested hstore

On 03/05/2014 11:44 AM, Bruce Momjian wrote: On Wed, Mar 5, 2014 at 11:16:01AM -0500, Tom Lane wrote: Bruce Momjian writes: It seems only pg_type.oid is an issue for hstore. We can easily modify pg_dump --binary-upgrade mode to suppress the creation of the hstore extension. That should all

Re: [HACKERS] jsonb and nested hstore

On 03/05/2014 12:01 PM, Bruce Momjian wrote: On Wed, Mar 5, 2014 at 11:53:31AM -0500, Andrew Dunstan wrote: I think we also have to break out how much of the feeling that JSONB is not ready is because of problems with the core/contrib split, and how much of it is because of the type itself

Re: [HACKERS] jsonb and nested hstore

On 03/06/2014 08:16 AM, Oleg Bartunov wrote: On Thu, Mar 6, 2014 at 12:43 PM, Peter Geoghegan wrote: On Thu, Mar 6, 2014 at 12:23 AM, Teodor Sigaev wrote: That's possible to introduce GUC variable for i/o functions which will control old "bug-to-bug" behavior. IMHO, this is much better optio

Re: [HACKERS] jsonb and nested hstore

On 03/06/2014 10:46 AM, Tom Lane wrote: Magnus Hagander writes: However, if the new hstore type (compatible with the old one) is the wrapper around jsonb, rather than the other way around, I don't see any problem with it at all. Most future users are almost certainly going to use the json inte

Re: [HACKERS] jsonb and nested hstore

On 03/06/2014 12:50 PM, Oleg Bartunov wrote: Hi there, Looks like consensus is done. I and Teodor are not happy with it, but what we can do :) One thing I want to do is to reserve our contribution to the flagship feature (jsonb), particularly, "binary storage for nested structures and in

Re: [HACKERS] jsonb and nested hstore

On 03/06/2014 11:33 PM, Bruce Momjian wrote: On Thu, Mar 6, 2014 at 09:50:56PM +0400, Oleg Bartunov wrote: Hi there, Looks like consensus is done. I and Teodor are not happy with it, but what we can do :) One thing I want to do is to reserve our contribution to the flagship feature (jsonb)

Re: [HACKERS] jsonb and nested hstore

On 03/07/2014 11:45 AM, Bruce Momjian wrote: On Fri, Mar 7, 2014 at 11:35:41AM -0500, Andrew Dunstan wrote: IIRC The sacrifice was one bit in the header (i.e. in the first int after the varlena header). We could now repurpose that (for example if we ever decided to use a new format). Oleg

Re: [HACKERS] jsonb and nested hstore

On 03/10/2014 05:18 AM, Peter Geoghegan wrote: On Fri, Mar 7, 2014 at 9:00 AM, Bruce Momjian wrote: OK, it sounds like the adjustments are minimal, like not using the high-order bit. Attached patch is a refinement of the work of Oleg, Teodor and Andrew. Revisions are mostly my own, although A

Re: [HACKERS] jsonb and nested hstore

On 03/10/2014 10:50 AM, Andrew Dunstan wrote: Thanks for your work on this. It's just occurred to me that we'll need to add hstore_to_jsonb functions and a cast to match the hstore_to_json functions and cast. That should be fairly simple - I'll work on that. It need not ho

Re: [HACKERS] db_user_namespace a "temporary measure"

On 03/11/2014 09:57 AM, Tom Lane wrote: Magnus Hagander writes: On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane wrote: Are you claiming there are no users, and if so, on what evidence? I am claiming that I don't think anybody is using that, yes. Based on the fact that I have *never* come across i

Re: [HACKERS] db_user_namespace a "temporary measure"

On 03/11/2014 12:37 PM, Stephen Frost wrote: Isn't the other issue for ISPs essentially that we don't have row-level security for our global catalogs? as in- we can't limit what's in pg_authid to only those entries a given user should be able to see? I don't think db_user_namespace addresses

Re: [HACKERS] db_user_namespace a "temporary measure"

On 03/11/2014 07:41 PM, Tom Lane wrote: Andrew Dunstan writes: The docs say: db_user_namespace causes the client's and server's user name representation to differ. Authentication checks are always done with the server's user name so authentication methods mus

Re: [HACKERS] db_user_namespace a "temporary measure"

On 03/11/2014 09:37 PM, Tom Lane wrote: In particular, I'd like to see an exclusion that prevents local users from having the same name as any global user, so that we don't have ambiguity in GRANT and similar commands. This doesn't seem simple to enforce (if we supported partial indexes on sy

Re: [HACKERS] db_user_namespace a "temporary measure"

On 03/11/2014 11:06 PM, Tom Lane wrote: Andrew Dunstan writes: On 03/11/2014 09:37 PM, Tom Lane wrote: In particular, I'd like to see an exclusion that prevents local users from having the same name as any global user, so that we don't have ambiguity in GRANT and similar comma

Re: [HACKERS] db_user_namespace a "temporary measure"

On 03/11/2014 11:50 PM, Jaime Casanova wrote: On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane wrote: But not sure how to define a unique index that allows (joe, db1) to coexist with (joe, db2) but not with (joe, 0). and why you want that restriction? when you login you need to specify the db, rig

Re: [HACKERS] Re: How to configer the pg_hba record which the database name with "\n" ?

On 08/07/2013 04:12 PM, Bruce Momjian wrote: On Thu, Aug 1, 2013 at 07:26:38AM -0700, David Johnston wrote: huxm wrote where there is a newline(\n) in the name. I can't imagine why you would want to use non-printing characters in a name, especially a database name. Even if the hba.conf fi

Re: [HACKERS] Proposal for XML Schema Validation

On 08/08/2013 12:42 AM, Kodamasimham Pridhvi (MT2012066) wrote: Hello pgsql-hackers , With reference to "Add XML Schema validation and xmlvalidate functions (SQL:2008)" in ToDo list, we have gone through pgsql-mailing list but we didn't find any significant work in this area, so we are

Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

On 08/12/2013 01:40 PM, Magnus Hagander wrote: I also like the concept of #2, but I think we need to think about it a bit more. One of the things I like about barman backups is that on recovery you can map where tablespaces go, on a per tablespace basis (it's not very well documented, or wasn't

Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

On 08/12/2013 02:22 PM, Magnus Hagander wrote: On Mon, Aug 12, 2013 at 8:14 PM, Andrew Dunstan wrote: On 08/12/2013 01:40 PM, Magnus Hagander wrote: I also like the concept of #2, but I think we need to think about it a bit more. One of the things I like about barman backups is that on

Re: [HACKERS] How to create read-only view on 9.3

On 08/13/2013 12:09 PM, Merlin Moncure wrote: On Tue, Aug 13, 2013 at 10:12 AM, Hannu Krosing wrote: On 08/13/2013 03:25 PM, Merlin Moncure wrote: I chatted about this on IRC for a bit. Apparently, updatability of views is a mandatory feature in the sql standard and by relying on the read-on

Re: [HACKERS] How to create read-only view on 9.3

On 08/13/2013 01:33 PM, Hannu Krosing wrote: In any case, using permissions is a somewhat leaky bandaid, since superusers have overriding access privileges anyway. A better way to do what the OP wants might be to have a view trigger that raises an exception. Superuser can easily disable or dr

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/17/2013 01:16 AM, Noah Misch wrote: On Fri, Aug 16, 2013 at 06:56:45PM -0500, Michael Cronenworth wrote: I started a thread on the general list so read that for more info. http://www.postgresql.org/message-id/520a6e55.40...@cchtml.com I'm also going to submit the patch to CommitFest. +#

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/17/2013 01:16 AM, Noah Misch wrote: On Fri, Aug 16, 2013 at 06:56:45PM -0500, Michael Cronenworth wrote: I started a thread on the general list so read that for more info. http://www.postgresql.org/message-id/520a6e55.40...@cchtml.com I'm also going to submit the patch to CommitFest. +#

Re: [HACKERS] warning in code while building on windows

On 08/18/2013 05:08 PM, Alvaro Herrera wrote: Amit Kapila escribió: 1>.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101: 'isnull' : unreferenced local variable It seems this variable is used only under macro USE_ASSERT_CHECKING, so it is better to declare under this macro only.

Re: [HACKERS] Automatic Index Creation for Column Types

On 08/19/2013 09:10 AM, Charles Sheridan wrote: Hi, I don't see indication that the capability described below exists in Postgres (or any RDBMS), so this is likely a feature request -- For column types that are frequently defined in tables, and which are typically indexed, it would be helpful

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/19/2013 09:50 AM, Michael Cronenworth wrote: On 08/18/2013 12:02 PM, Andrew Dunstan wrote: There is a much simpler fix, which is to do these assignments unconditionally in src/port/win32.h. The following small change fixes the problem for me: No. Please do not do this. If you object

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/19/2013 10:35 AM, Robert Haas wrote: TBH, I think Andrew is going above and beyond the call of duty by developing and testing a patch for the problem you reported. I've actually known about this problem for a while, but mistakenly thought it only occurred for cross-compilation:

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/19/2013 11:36 PM, Michael Cronenworth wrote: On 08/19/2013 07:35 PM, Noah Misch wrote: That was option #1. (You weren't planning to change just the one symbol causing the failure at hand, were you?) Reasonable choice. The point in the code comment quoted above looks bad, but the lack

Re: [HACKERS] Unpacking scalar JSON values

On 08/24/2013 09:08 PM, Daniel Farina wrote: On Sat, Aug 24, 2013 at 6:04 PM, Daniel Farina wrote: But there's no good way I can find from the documentation to do it with a scalar: select ('"va\"lue"'::json)::text; Triggered send by accident: select ('"va\"lue"'::json)::text; text --

Re: [HACKERS] pg_dump/restore encoding woes

On 08/27/2013 10:36 AM, Heikki Linnakangas wrote: 0001-Divorce-pg_dump-E-option-from-PGCLIENTENCODING.patch Separates pg_dump -E from PGCLIENTENCODING. Wouldn't it be better to do this another way? Separating these two will be confusing, to say the least, as well as inconsistent with what

Re: [HACKERS] pg_dump/restore encoding woes

On 08/27/2013 11:14 AM, Heikki Linnakangas wrote: On 27.08.2013 18:03, Andrew Dunstan wrote: On 08/27/2013 10:36 AM, Heikki Linnakangas wrote: 0001-Divorce-pg_dump-E-option-from-PGCLIENTENCODING.patch Separates pg_dump -E from PGCLIENTENCODING. Wouldn't it be better to do this anothe

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/29/2013 05:31 PM, David E. Wheeler wrote: On Aug 29, 2013, at 2:22 PM, Pavel Stehule wrote: Still I don't think so correct solution is enabling a unbound SELECTs, but correct is a fix a PERFORM and remove a necessity to use a PERFORM for call of VOID functions. Well, in this thread,

Re: [HACKERS] Variadic aggregates vs. project policy

On 08/29/2013 05:37 PM, Josh Berkus wrote: Tom, On further reflection, what the "policy" was actually about was not that we should forbid users from creating potentially-confusing aggregates themselves, but only that we'd avoid having any *built in* aggregates with this hazard. So maybe I'm o

[HACKERS] max freeze age query in docs

The other day I followed the docs and ran this query: SELECT relname, age(relfrozenxid) FROM pg_class WHERE relkind = 'r'; Then after identifying some tables that were close to triggering an automatic vacuum, we vacuumed them only to find that the age of the database's datfrozenxid hadn't

Re: [HACKERS] max freeze age query in docs

On 09/01/2013 10:33 PM, Josh Berkus wrote: Maybe for bonus points we'd print out the schema (e.g. by selectting c.oid::regclass instead of c.relname), and also include materialized views which are omitted from the query altogether. Given the importance of this, maybe we need to have it as part

Re: [HACKERS] max freeze age query in docs

On 09/02/2013 01:30 PM, Tom Lane wrote: Andrew Dunstan writes: Yes, possibly, but we can't do that now, but I would like to fix the docs now. If you want this in 9.3.0 it needs to be committed in the next couple of hours. FWIW, the idea seemed generally sane to me, but I'd s

Re: [HACKERS] max freeze age query in docs

On 09/02/2013 02:26 PM, Andres Freund wrote: On 2013-09-02 14:20:57 -0400, Andrew Dunstan wrote: On 09/02/2013 01:30 PM, Tom Lane wrote: Andrew Dunstan writes: Yes, possibly, but we can't do that now, but I would like to fix the docs now. If you want this in 9.3.0 it needs to be comm

Re: [HACKERS] Bugfix and new feature for PGXS

On 09/03/2013 04:02 AM, Cédric Villemain wrote: Simple one, attached. I didn't document USE_VPATH, not sure how to explain that clearly. Just a remember that the doc is written and is waiting to be commited. There is also an issue spoted by Christoph with the installdirs prerequisite, the atta

Re: [HACKERS] memory usage of pg_upgrade

On 09/09/2013 06:20 PM, Jeff Janes wrote: pg_upgrade reserves 5 times MAXPGPATH, or 5120 characters, for the tablespace name of every object (table, toast table, index) in the database being upgraded. This adds up pretty quickly when there is a very large number of objects. It could be changed

Re: [HACKERS] Protocol forced to V2 in low-memory conditions?

On 09/11/2013 02:30 PM, Robert Haas wrote: On Tue, Sep 10, 2013 at 9:53 AM, Tom Lane wrote: Andres Freund writes: On 2013-09-10 12:31:22 +0200, Magnus Hagander wrote: On Tue, Sep 10, 2013 at 5:29 AM, Tom Lane wrote: I've been thinking of late that it might be time to retire libpq's suppor

Re: [HACKERS] Successor of MD5 authentication, let's use SCRAM

On 09/12/2013 09:10 AM, Heikki Linnakangas wrote: Now, to a completely different approach: I just found out that OpenSSL has added support for SRP in version 1.0.1. We're already using OpenSSL, so all we need to do is to provide a couple of callbacks to OpenSSL, and store SRP verifiers in p

Re: [HACKERS] git apply vs patch -p1

On 09/14/2013 02:37 PM, Josh Berkus wrote: Folks, Lately I've been running into a lot of reports of false conflicts reported by "git apply". The most recent one was the "points" patch, which git apply rejected for completely ficticious reasons (it claimed that the patch was trying to create a

[HACKERS] json docs fixup

While writing slides for pgopen next week, I noticed that the JSON docs on json_populate_record and json_populate_recordset contain this sentence: A column may only be specified once. IIRC we removed that restriction during development, so unless there is a squawk I am going to simply r

Re: [HACKERS] git apply vs patch -p1

On 09/14/2013 03:08 PM, Andres Freund wrote: On 2013-09-14 15:03:52 -0400, Andrew Dunstan wrote: On 09/14/2013 02:37 PM, Josh Berkus wrote: Folks, Lately I've been running into a lot of reports of false conflicts reported by "git apply". The most recent one was the "poin

Re: [HACKERS] Proposal: json_populate_record and nested json objects

On 09/14/2013 10:27 PM, chris travers wrote: Hi all; Currently json_populate_record and json_populate_recordset cannot work with nested json objects. This creates two fundamental problems when trying to use JSON as an interface format. The first problem is you can't easily embed a json data t

Re: [HACKERS] Where to load modules from?

On 09/15/2013 05:52 PM, Jeff Janes wrote: On Sun, Sep 15, 2013 at 6:51 AM, Peter Eisentraut > wrote: On Sat, 2013-09-14 at 22:15 +0200, Dimitri Fontaine wrote: > > This proposal comes with no patch because I think we are able to > understand it without th

Re: [HACKERS] Proposal: json_populate_record and nested json objects

On 09/16/2013 09:57 AM, Chris Travers wrote: > On 16 September 2013 at 14:43 Merlin Moncure wrote: > > Huge +1 on on this. Couple random thoughts: > > *) Hard to see how you would structure this as an extension as you're > adjusting the behaviors of existing functions, unless you wanted to

Re: [HACKERS] VMs for Reviewers Available

On 09/21/2013 06:48 PM, Peter Geoghegan wrote: On Sat, Sep 21, 2013 at 3:35 PM, Josh Berkus wrote: Windows VMs are also available, but I don't have the ability to preconfigure them with tools. Wasn't there an EC2 image doing the rounds that Magnus created, that took care of all of that for yo

Re: [HACKERS] VMs for Reviewers Available

On 09/21/2013 10:48 PM, Jaime Casanova wrote: El 21/09/2013 18:09, "Andrew Dunstan" <mailto:and...@dunslane.net>> escribió: > > > On 09/21/2013 06:48 PM, Peter Geoghegan wrote: >> >> On Sat, Sep 21, 2013 at 3:35 PM, Josh Berkus <mailto:j...@agliodbs

Re: [HACKERS] PostgreSQL 9.3 beta breaks some extensions "make install"

On 09/23/2013 11:31 AM, Alvaro Herrera wrote: Marti Raudsepp wrote: On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp wrote: Oh I see, indeed commit 6697aa2bc25c83b88d6165340348a31328c35de6 "Improve support for building PGXS modules with VPATH" fixes the problem and I see it's not present in RE

Re: [HACKERS] 9.3 Json & Array's

On 09/24/2013 12:59 AM, Chris Travers wrote: I am still in the process of wrapping my head around the current JSON logic. I hope to produce a proof of concept that can later be turned into a patch. See my previous post on this topic. Again collaboration is welcome. Feel free to ask

Re: [HACKERS] PostgreSQL 9.3 beta breaks some extensions "make install"

On 09/23/2013 12:15 PM, Cédric Villemain wrote: I'm working on it. It appears to have a slight problem or two I want to fix at the same time, rather than backpatch something broken. Would you mind sharing the problems you are facing ? You've noticed the problem about installdirs, I suppose. Th

[HACKERS] hstore extension version screwup

When adding json support to hstore, I made a major blunder and added the new functionality to the existing sql script instead of bumping the version, renaming the script and adding an update script. This was lazy and there's no real excuse, although I will note that it was a mistake far too

Re: [HACKERS] Bugfix and new feature for PGXS

On 09/03/2013 04:04 AM, Cédric Villemain wrote: Simple one, attached. I didn't document USE_VPATH, not sure how to explain that clearly. Just a remember that the doc is written and is waiting to be commited. There is also an issue spoted by Christoph with the installdirs prerequisite, the atta

Re: [HACKERS] hstore extension version screwup

On 09/29/2013 09:58 PM, Peter Eisentraut wrote: On Fri, 2013-09-27 at 13:23 -0400, Andrew Dunstan wrote: This was lazy and there's no real excuse, although I will note that it was a mistake far too easy to make. Perhaps as a warning indicator we should remove write permissions from these

Re: [HACKERS] hstore extension version screwup

On 09/29/2013 10:38 PM, Peter Eisentraut wrote: On Sun, 2013-09-29 at 22:33 -0400, Andrew Dunstan wrote: Well if these are not meant to be changed then not being able to write them in your git repo might be a clue to that. Git doesn't support setting file permissions other than the execu

Re: [HACKERS] Bugfix and new feature for PGXS

On 09/29/2013 07:09 PM, Andrew Dunstan wrote: On 09/03/2013 04:04 AM, Cédric Villemain wrote: Simple one, attached. I didn't document USE_VPATH, not sure how to explain that clearly. Just a remember that the doc is written and is waiting to be commited. There is also an issue spot

Re: [HACKERS] [PATCH] pg_upgrade: support for btrfs copy-on-write clones

On 10/01/2013 06:31 PM, Oskari Saarenmaa wrote: Add file cloning as an alternative data transfer method to pg_upgrade. Currently only btrfs is supported, but copy-on-write cloning is also available on at least ZFS. Cloning must be requested explicitly and if it isn't supported by the operating

[HACKERS] old warning in docs

Given that we have not supported releases older than 8.3 for quite a while, do we need to keep this in extend.sgml any longer? Changing PG_CONFIG only works when building against PostgreSQL 8.3 or later. With older releases it does not work to set it to anything except

Re: [HACKERS] Patch: FORCE_NULL option for copy COPY in CSV mode

On 10/07/2013 03:06 PM, Robert Haas wrote: Also if your use case is to treat empty strings as NULL (as per above documentation), can't it be handled with "WITH NULL AS" option. For example, something like: postgres=# COPY testnull FROM stdin with CSV NULL AS E''; Enter data to be copied follo

Re: [HACKERS] Bugfix and new feature for PGXS

On 10/07/2013 08:47 PM, Peter Eisentraut wrote: On Sun, 2013-09-29 at 19:09 -0400, Andrew Dunstan wrote: On 09/03/2013 04:04 AM, Cédric Villemain wrote: Simple one, attached. I didn't document USE_VPATH, not sure how to explain that clearly. Just a remember that the doc is written a

Re: [HACKERS] Patch: FORCE_NULL option for copy COPY in CSV mode

On 10/07/2013 11:34 PM, Amit Kapila wrote: On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan wrote: On 10/07/2013 03:06 PM, Robert Haas wrote: Also if your use case is to treat empty strings as NULL (as per above documentation), can't it be handled with "WITH NULL AS" opti

Re: [HACKERS] Bugfix and new feature for PGXS

On 10/07/2013 08:47 PM, Peter Eisentraut wrote: I suspect this line submake-libpq: $(libdir)/libpq.so ; will cause problems on platforms with a different extension (e.g. OS X). suggested fix is below. cheers andrew diff --git a/src/Makefile.global.in b/src/Makefile.global.in index bb732

Re: [HACKERS] Patch: FORCE_NULL option for copy COPY in CSV mode

On 10/08/2013 12:30 PM, Robert Haas wrote: On Tue, Oct 8, 2013 at 8:33 AM, Andrew Dunstan wrote: On 10/07/2013 11:34 PM, Amit Kapila wrote: On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan wrote: On 10/07/2013 03:06 PM, Robert Haas wrote: Also if your use case is to treat empty strings as

Re: [HACKERS] Patch: FORCE_NULL option for copy COPY in CSV mode

On 10/08/2013 12:47 PM, Andrew Dunstan wrote: On 10/08/2013 12:30 PM, Robert Haas wrote: Andrew, are you planning to review & commit this? Yes. Incidentally, the patch doesn't seem to add the option to file_fdw, which I really think it should. cheers andrew -- Sent

Re: [HACKERS] Patch: FORCE_NULL option for copy COPY in CSV mode

On 10/09/2013 09:22 AM, Amit Kapila wrote: On Wed, Oct 9, 2013 at 9:15 AM, Amit Kapila wrote: On Tue, Oct 8, 2013 at 6:03 PM, Andrew Dunstan wrote: On 10/07/2013 11:34 PM, Amit Kapila wrote: On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan wrote: On 10/07/2013 03:06 PM, Robert Haas wrote

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

On 10/09/2013 10:45 AM, Bruce Momjian wrote: On Wed, Oct 9, 2013 at 04:40:38PM +0200, Pavel Stehule wrote: Effectively, if every session uses one full work_mem, you end up with total work_mem usage equal to shared_buffers. We can try a different algorithm to scale up work_mem,

Re: [HACKERS] Patch: FORCE_NULL option for copy COPY in CSV mode

On 10/09/2013 11:23 AM, Dimitri Fontaine wrote: Andrew Dunstan writes: I don't see at all that your suggested alternative has any advantages over what's been written. If you can say "NULL FOR (foo) as '""' how will you specify the null for some other colum

Re: [HACKERS] Patch: FORCE_NULL option for copy COPY in CSV mode

On 10/09/2013 01:25 PM, David Fetter wrote: Idea: NULL FOR (foo,bar,baz,blurf) AS '""', NULL FOR (quux,fleeg) AS ..., What's the point of this? How is this superior to what is currently proposed? Having arbitrary NULL markers for different fields will significantly increase code complex

Re: [HACKERS] Patch: FORCE_NULL option for copy COPY in CSV mode

On 10/09/2013 03:25 PM, Robert Haas wrote: Therefore, a user who wants the opposite of the default behavior - namely, unquoted empty strings as empty strings and quoted empty strings as nulls - should specify both FORCE NULL and FORCE NOT NULL. Is there a real world example of this case? How

Re: [HACKERS] Patch: FORCE_NULL option for copy COPY in CSV mode

On 10/09/2013 08:39 PM, Robert Haas wrote: On Wed, Oct 9, 2013 at 5:43 PM, Andrew Dunstan wrote: On 10/09/2013 03:25 PM, Robert Haas wrote: Therefore, a user who wants the opposite of the default behavior - namely, unquoted empty strings as empty strings and quoted empty strings as nulls

Re: [HACKERS] Patch: FORCE_NULL option for copy COPY in CSV mode

On 10/09/2013 11:47 PM, Amit Kapila wrote: One of the advantage, I could see using "NULL For .." syntax is that already we have one syntax with which user can specify what strings can be replaced with NULL, now just to handle quoted empty string why to add different syntax. "FORCE_NULL" ha

Re: [HACKERS] Add json_typeof() and json_is_*() functions.

On 08/06/2013 08:42 AM, Robert Haas wrote: On Fri, Aug 2, 2013 at 8:22 AM, Andrew Tipton wrote: But without json_is_scalar(), the choice is one of these two forms: json_typeof() NOT IN ('object', 'array') json_typeof() IN ('string', 'number', 'boolean', 'null') The first of those is wha

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

On 10/10/2013 12:28 PM, Bruce Momjian wrote: How do we handle the Python dependency, or is this all to be done in some other language? I certainly am not ready to take on that job. Without considering any wider question here, let me just note this: Anything that can be done in this area in

Re: [HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

On 09/19/2013 06:12 PM, Pavel Stehule wrote: 2013/9/16 Satoshi Nagayasu mailto:sn...@uptime.jp>> I'm looking at this patch, and I have a question here. Should "DROP TRIGGER IF EXISTS" ignore error for non-existing trigger and non-existing table? Or just only for non-existin

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

On 10/10/2013 12:45 PM, Bruce Momjian wrote: On Thu, Oct 10, 2013 at 12:39:04PM -0400, Andrew Dunstan wrote: On 10/10/2013 12:28 PM, Bruce Momjian wrote: How do we handle the Python dependency, or is this all to be done in some other language? I certainly am not ready to take on that job

Re: [HACKERS] dynamic shared memory: wherein I am punished for good intentions

On 10/10/2013 12:13 PM, Robert Haas wrote: Since, as has been previously discussed in this forum on multiple occasions [citation needed], the default System V shared memory limits are absurdly low on many systems, the dynamic shared memory patch defaults to POSIX shared memory, which has often b

Re: [HACKERS] dynamic shared memory: wherein I am punished for good intentions

On 10/10/2013 02:35 PM, Robert Haas wrote: On Thu, Oct 10, 2013 at 2:21 PM, Andrew Dunstan wrote: Other votes? Other ideas? 5) test and set it in initdb. Are you advocating for that option, or just calling out that it's possible? I'd say that's closely related to optio

Re: [HACKERS] dynamic shared memory: wherein I am punished for good intentions

On 10/10/2013 02:45 PM, Robert Haas wrote: On Thu, Oct 10, 2013 at 2:36 PM, Peter Geoghegan wrote: On Thu, Oct 10, 2013 at 9:13 AM, Robert Haas wrote: (2) Default to using System V shared memory. If people want POSIX shared memory, let them change the default. After some consideration, I th

Re: [HACKERS] Bugfix and new feature for PGXS

On 10/10/2013 09:37 PM, Peter Eisentraut wrote: On Mon, 2013-10-07 at 22:00 -0400, Andrew Dunstan wrote: The code has been sitting in HEAD for several months, and I committed on the back branches because it was wanted. New features normally go through a full development cycle including

Re: [HACKERS] Bugfix and new feature for PGXS

On 10/10/2013 09:35 PM, Peter Eisentraut wrote: On Tue, 2013-10-08 at 10:04 -0400, Andrew Dunstan wrote: On 10/07/2013 08:47 PM, Peter Eisentraut wrote: I suspect this line submake-libpq: $(libdir)/libpq.so ; will cause problems on platforms with a different extension (e.g. OS X

Re: [HACKERS] [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation

On 10/11/2013 03:57 AM, Tom Lane wrote: Peter Eisentraut writes: Replace duplicate_oids with Perl implementation It is more portable, more robust, and more readable. From: Andrew Dunstan What about unused_oids? Here's a quick version I whipped up along the

Re: [HACKERS] buildfarm failures on smew and anole

On 10/11/2013 03:33 PM, Robert Haas wrote: The build is continuing to fail on smew and anole. The reason it's failing is because those machines are choosing max_connections = 10, which is not enough to run the regression tests. I think this is probably because of System V semaphore exhaustion.

Re: [HACKERS] buildfarm failures on smew and anole

On 10/14/2013 09:12 AM, Robert Haas wrote: On Fri, Oct 11, 2013 at 4:03 PM, Andrew Dunstan wrote: Can the owners of these buildfarm machines please check whether there are extra semaphores allocated and if so free them? Or at least reboot, to see if that unbreaks the build? It is possible

Re: [HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

On 10/14/2013 05:44 PM, Andres Freund wrote: On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote: On 09/19/2013 06:12 PM, Pavel Stehule wrote: 2013/9/16 Satoshi Nagayasu mailto:sn...@uptime.jp>> I'm looking at this patch, and I have a question here. Should "

<    2   3   4   5   6   7   8   9   10   11   >