Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On 06.06.2017 14:31, Bruce Momjian wrote: On Tue, Jun 6, 2017 at 04:39:50AM -0300, Alvaro Herrera wrote: I was thinking that you could create the init fork for each unlogged table in a permanent tablespace (probably the default one for the database). FWIW I don't think calling these

Re: [HACKERS] Surjective functional indexes

On 29.05.2017 21:25, Sven R. Kunze wrote: [...] non-surjective functions. non-injective of course -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Surjective functional indexes

On 29.05.2017 19:21, Christoph Berg wrote: I think the term you were looking for is "projection". https://en.wikipedia.org/wiki/Projection_(set_theory) Maybe, I am seeing too much of a connection here but recently Raymond Hettinger held a very interesting talk [1] at PyCon 2017. For those

Re: [HACKERS] Adding support for Default partition in partitioning

On 10.05.2017 17:59, Robert Haas wrote: Well, I don't think it would be a HUGE problem, but I think the fact that Amit chose to implement this with syntax similar to that of Oracle is probably not a coincidence, but rather a goal, and I think the readability problem that you're worrying about is

Re: [HACKERS] Adding support for Default partition in partitioning

com <mailto:robertmh...@gmail.com>> wrote: On Thu, May 4, 2017 at 4:40 PM, Sven R. Kunze <srku...@mail.de <mailto:srku...@mail.de>> wrote: > It yields > > CREATE TABLE p1 PARTITION OF test DEFAULT PARTITION BY LIST(b); > > T

Re: [HACKERS] WITH clause in CREATE STATISTICS

On 04.05.2017 23:13, Tom Lane wrote: I'm not against what you've done here, because I had no love for USING in this context anyway; it conveys approximately nothing to the mind about what is in the list it's introducing. But I'm concerned whether we're boxing ourselves in by using ON.

Re: [HACKERS] Missing feature in Phrase Search?

Hi everybody, On 21.04.2017 20:47, Josh Berkus wrote: Oleg, Teodor, folks: I was demo'ing phrase search for a meetup yesterday, and the user feedback I got showed that there's a missing feature with phrase search. Let me explain by example: 'fix <-> error' will match 'fixed error', 'fixing

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Rahila, still thinking about the syntax (sorry): On 04.05.2017 13:44, Rahila Syed wrote: [...] The syntax implemented in this patch is as follows, CREATE TABLE p11 PARTITION OF p1 DEFAULT; Rewriting the following: On Thu, May 4, 2017 at 4:02 PM, amul sul

Re: [HACKERS] Adding support for Default partition in partitioning

On 27.04.2017 22:21, Robert Haas wrote: On Thu, Apr 27, 2017 at 3:15 PM, Sven R. Kunze <srku...@mail.de> wrote: Just to make sound a little rounder: CREATE TABLE ... PARTITION OF ... AS DEFAULT CREATE TABLE ... PARTITION OF ... AS FALLBACK or CREATE TABLE ... PARTITION OF ... AS D

Re: [HACKERS] Adding support for Default partition in partitioning

On 27.04.2017 15:07, Robert Haas wrote: On Thu, Apr 27, 2017 at 8:49 AM, Rahila Syed wrote: +1 for CREATE TABLE..PARTITION OF...DEFAULT syntax. I think substituting DEFAULT for FOR VALUES is appropriate as both cases are mutually exclusive. Just to make sound a little

Re: [HACKERS] multivariate statistics (v25)

Thanks Tomas and David for hacking on this patch. On 04.04.2017 20:19, Tomas Vondra wrote: I'm not sure we still need the min_group_size, when evaluating dependencies. It was meant to deal with 'noisy' data, but I think it after switching to the 'degree' it might actually be a bad idea.

Re: [HACKERS] [PATCH] few fts functions for jsonb

On 03.04.2017 21:30, Andrew Dunstan wrote: On 04/03/2017 02:44 PM, Sven R. Kunze wrote: On 01.04.2017 22:20, Andrew Dunstan wrote: I added documentation when I committed it for the new functions, in the FTS section. I'm not sure what we need to add to the JSON section if anything. Not sure

Re: [HACKERS] [PATCH] few fts functions for jsonb

On 01.04.2017 22:20, Andrew Dunstan wrote: I added documentation when I committed it for the new functions, in the FTS section. I'm not sure what we need to add to the JSON section if anything. Not sure, if this is related but the formatting of

Re: [HACKERS] SQL/JSON in PostgreSQL

On 13.03.2017 07:24, Nico Williams wrote: On Thu, Mar 09, 2017 at 07:12:07PM +0100, Sven R. Kunze wrote: From my day-to-day work I can tell, the date(time) type is the only missing piece of JSON to make it perfect for business applications (besides, maybe, a "currency" type). An

Re: [HACKERS] SQL/JSON in PostgreSQL

On 10.03.2017 20:28, Josh Berkus wrote: On 03/09/2017 10:12 AM, Sven R. Kunze wrote: SaltStack uses YAML for their tools, too. I personally can empathize with them (as a user of configuration management) about this as writing JSON would be nightmare with all the quoting, commas, curly braces

Re: [HACKERS] SQL/JSON in PostgreSQL

On 10.03.2017 05:07, Petr Jelinek wrote: The original complain was about JSON_VALUE extracting date but I don't understand why there is problem with that, the SQL/JSON defines that behavior. The RETURNING clause there is more or less just shorthand for casting with some advanced options.

Re: [HACKERS] adding an immutable variant of to_date

On 08.03.2017 03:37, Robert Haas wrote: The commit message for 64353640e87b54250f1b8a1d2a708d270dff4bfd has some interesting perspective on this. """ Also, mark to_date() and to_char(interval) as stable; although these appear not to depend on any GUC variables as of CVS HEAD, that seems a

Re: [HACKERS] adding an immutable variant of to_date

Thanks! On 08.03.2017 17:37, Andreas Karlsson wrote: The current code for to_char will on the first call to to_char build arrays with the localized names of the week days and the months. I suspect that you may need to build something similar but a set of arrays per locale. Not sure what the

Re: [HACKERS] SQL/JSON in PostgreSQL

On 09.03.2017 19:50, Peter van Hardenberg wrote: Anecdotally, we just stored dates as strings and used a convention (key ends in "_at", I believe) to interpret them. The lack of support for dates in JSON is well-known, universally decried... and not a problem the PostgreSQL community can fix.

Re: [HACKERS] SQL/JSON in PostgreSQL

On 09.03.2017 18:58, Robert Haas wrote: Also, even if the superset thing were true on a theoretical plane, I'm not sure it would do us much good in practice. If we start using YAML-specific constructs, we won't have valid JSON any more. If we use only things that are legal in JSON, YAML's

Re: [HACKERS] SQL/JSON in PostgreSQL

On 08.03.2017 20:52, Magnus Hagander wrote: On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg > wrote: Small point of order: YAML is not strictly a super-set of JSON. Editorializing slightly, I have not seen much interest in the world for YAML

Re: [HACKERS] SQL/JSON in PostgreSQL

On 08.03.2017 20:48, Peter van Hardenberg wrote: Small point of order: YAML is not strictly a super-set of JSON. I haven't read the whole standard, but from what I can see the standard considers JSON an official subset of itself: http://www.yaml.org/spec/1.2/spec.html Regards, Sven --

Re: [HACKERS] SQL/JSON in PostgreSQL

Hi, about the datetime issue: as far as I know, JSON does not define a serialization format for dates and timestamps. On the other hand, YAML (as a superset of JSON) already supports a language-independent date(time) serialization format (http://yaml.org/type/timestamp.html). I haven't

Re: [HACKERS] adding an immutable variant of to_date

On 07.03.2017 03:21, Andreas Karlsson wrote: 1) I do not think we currently allow setting the locale like this anywhere, so this will introduce a new concept to PostgreSQL. And you will probably need to add support for caching per locale. Good to know. Could you explain what you mean by

[HACKERS] adding an immutable variant of to_date

Hello everybody, following up on this thread: https://www.postgresql.org/message-id/flat/d297e048-ac49-9bed-32e3-9dd4e65d0978%40mail.de specifically on this mail: https://www.postgresql.org/message-id/baef819f-acf0-a64d-c1eb-d2c5da1e5030%40mail.de I hope this idea fulfills the requirements. So

Re: [HACKERS] Indirect indexes

On 21.10.2016 22:54, Jim Nasby wrote: On 10/21/16 2:48 PM, Sven R. Kunze wrote: You don't need that limitation (and vacuum will be simpler) if you add the PK as another key, akin to: CREATE INDIRECT INDEX idx ON tab (a, b, c); turns into CREATE INDEX idx ON tab (a, b, c, pk); I know I

Re: [HACKERS] Indirect indexes

On 2016-10-18 20:04:32, Claudio Freire wrote: > You don't need that limitation (and vacuum will be simpler) if you add the PK as another key, akin to: > > CREATE INDIRECT INDEX idx ON tab (a, b, c); > > turns into > > CREATE INDEX idx ON tab (a, b, c, pk); I know I am late to this point but I