Re: [HACKERS] Proposal: knowing detail of config files via SQL

On Fri, Jan 30, 2015 at 12:05 PM, David Fetter wrote: > On Sat, Jan 31, 2015 at 12:50:20AM +0900, Sawada Masahiko wrote: > > > > [postgres][5432](1)=# select * from pg_file_settings where name = > 'work_mem'; > > -[ RECORD 1 ]-- > > name |

Re: [HACKERS] Small bug on CREATE EXTENSION pgq...

On Wednesday, January 28, 2015, Stephen Frost wrote: > * David G Johnston (david.g.johns...@gmail.com ) wrote: > > Jerry Sievers-3 wrote > > > Hackers; I noticed this trying to import a large pg_dump file with > > > warnings supressed. > > > > > > It seems loading pgq sets client_min_messages to

Re: [HACKERS] Proposal: knowing detail of config files via SQL

On Thu, Jan 22, 2015 at 3:19 PM, Tom Lane wrote: > David Johnston writes: > > On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane wrote: > >> Is that a requirement, and if so why? Because this proposal doesn't > >> guarantee any such knowledge AFAICS. > > > ​Th

Re: [HACKERS] Proposal: knowing detail of config files via SQL

On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane wrote: > David G Johnston writes: > > Tom Lane-2 wrote > >> regression=# alter system reset timezone; > >> ALTER SYSTEM > >> regression=# select pg_reload_conf(); > > > How does someone know that performing the above commands will result in > the > > Tim

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Tue, Jan 20, 2015 at 8:46 PM, Robert Haas wrote: > On Tue, Jan 20, 2015 at 4:07 PM, David Johnston > wrote: > > sourceline and sourcefile pertain only to the current value while the > point > > of adding these other pieces is to provide a snapshot of all the > differe

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Tue, Jan 20, 2015 at 1:24 PM, Jim Nasby wrote: > On 1/16/15 10:32 PM, David G Johnston wrote: > Two changes solve this problem in what seems to be a clean way. >> 1) Upon each parsing of postgresql.conf we store all assigned variables >> somewhere >> > > Parsing is relatively cheap, and it'

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Fri, Jan 16, 2015 at 10:19 PM, Amit Kapila wrote: > On Sat, Jan 17, 2015 at 10:41 AM, David Johnston < > david.g.johns...@gmail.com> wrote: > > On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila > wrote: > >> > >> On Sat, Jan 17, 2015 at 10:02 AM, David G

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila wrote: > On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston < > david.g.johns...@gmail.com> wrote: > > > You're right. > > > pg_setting and SHOW command use value in current session rather than > > > config file. > > > It might break these common infr

Re: [HACKERS] Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs

On Tue, Jan 6, 2015 at 4:15 PM, Jim Nasby wrote: > On 1/6/15, 10:32 AM, Alvaro Herrera wrote: > >> Tom Lane wrote: >> >> What would make sense to me is to teach the planner about inlining >>> SQL functions that include ORDER BY clauses, so that the performance >>> issue of a double sort could be

Re: [HACKERS] [GENERAL] ON_ERROR_ROLLBACK

On Tue, Dec 30, 2014 at 8:54 AM, Adrian Klaver wrote: > On 12/30/2014 07:43 AM, David G Johnston wrote: > >> Tom Lane-2 wrote >> >>> Bernd Helmle < >>> >> >> mailings@ >>> >> >> > writes: >>> --On 29. Dezember 2014 12:55:11 -0500 Tom Lane < >>> >> tgl@.pa >>> >> >> > wrote: >>>

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 2:05 PM, Bruce Momjian wrote: > On Thu, Dec 11, 2014 at 10:04:43AM -0700, David G Johnston wrote: > > Tom Lane-2 wrote > > > Robert Haas < > > > > > robertmhaas@ > > > > > > writes: > > >> On Thu, Dec 11, 2014 at 1:18 AM, Josh Berkus < > > > > > josh@ > > > > > > wrote: >

Re: [HACKERS] Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4

On Thu, Nov 13, 2014 at 5:47 PM, Tom Lane wrote: > David G Johnston writes: > > Tom Lane-2 wrote > >> In the meantime, I assume that your real data contains a small > percentage > >> of values other than these two? If so, maybe cranking up the statistics > >> target would help. If the planner

Re: [HACKERS] controlling psql's use of the pager a bit more

On Thu, Nov 13, 2014 at 10:55 AM, Merlin Moncure wrote: > On Thu, Nov 13, 2014 at 11:39 AM, Robert Haas > wrote: > > On Thu, Nov 13, 2014 at 11:54 AM, David G Johnston > > wrote: > >>> Because I might be quite happy with 100 or 200 lines I can just scroll > >>> in my terminal's scroll buffer, b

Re: [HACKERS] Trailing comma support in SELECT statements

On Fri, Oct 24, 2014 at 6:36 AM, Alex Goncharov < alex.goncharov@gmail.com> wrote: > On Tue, Oct 21, 2014 at 10:16 AM, Tom Lane wrote: > >> (Of course, I'm not for the feature w.r.t. SQL either. But breaking data >> compatibility is just adding an entire new dimension of trouble. >> > > Anot

Re: [HACKERS] idea: allow AS label inside ROW constructor

On Thu, Oct 23, 2014 at 8:51 AM, Andrew Dunstan wrote: > > On 10/23/2014 11:36 AM, David G Johnston wrote: > >> Andrew Dunstan wrote >> >>> On 10/23/2014 09:57 AM, Florian Pflug wrote: >>> On Oct23, 2014, at 15:39 , Andrew Dunstan < >>> andrew@ >>> > wrote: >>> On 10/23/2014 09:27

Re: [HACKERS] Trailing comma support in SELECT statements

> > ​ > ​ > >> We might as well allow a final trailing (or initial leading) comma on a >> values list at the same time: >> >> VALUES >> (...), >> (...), >> (...), >> > ​ > > do you know, so this feature is a proprietary and it is not based on > ANSI/SQL? Any user, that use this feature and will to

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Friday, September 26, 2014, Alvaro Herrera wrote: > David Johnston wrote: > > On Friday, September 26, 2014, Alvaro Herrera > > > wrote: > > > > > Tom Lane wrote: > > > > > > > The impression I had was that Stephen was thinking of act

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Friday, September 26, 2014, Alvaro Herrera wrote: > Tom Lane wrote: > > > The impression I had was that Stephen was thinking of actually setting > > min_val to 1 (or whatever) and handling zero or -1 in some out-of-band > > fashion, perhaps by adding GUC flag bits showing those as allowable >

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Fri, Sep 26, 2014 at 2:27 PM, Stephen Frost wrote: > > Agreed- they're independent considerations and the original concern was > about the nonzero-to-zero issue, so I'd suggest we address that first, > though in doing so we will need to consider what *actual* min values we > should have for so

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Fri, Sep 26, 2014 at 2:02 PM, Robert Haas wrote: > On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote: > > Robert Haas writes: > >> If we want the narrowest possible fix for this, I think it's "complain > >> if a non-zero value would round to zero". That fixes the original > >> complaint and c

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote: > Robert Haas writes: > > If we want the narrowest possible fix for this, I think it's "complain > > if a non-zero value would round to zero". That fixes the original > > complaint and changes absolutely nothing else. But I think that's > > kind

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Thursday, September 25, 2014, Gregory Smith wrote: > On 9/25/14, 1:41 AM, David Johnston wrote: > >> If the error message is written correctly most people upon seeing the >> error will simply fix their configuration and move on - regardless of >> whether they were proa

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Thu, Sep 25, 2014 at 1:04 AM, Tom Lane wrote: > David Johnston writes: > > On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane wrote: > >> TBH I've also been wondering whether any of these proposed cures are > >> better than the disease. The changes that can be argue

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane wrote: > Gregory Smith writes: > > I don't see any agreement on the real root of a problem here yet. That > > makes gauging whether any smaller change leads that way or not fuzzy. I > > personally would be fine doing nothing right now, instead waiting

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Thu, Sep 25, 2014 at 12:11 AM, Gregory Smith wrote: > On 9/24/14, 6:45 PM, Peter Eisentraut wrote: > >> But then this proposal is just one of several others that break backward >> compatibility, and does so in a more or less silent way. Then we might >> as well pick another approach that gets

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Tue, Sep 23, 2014 at 10:11 PM, Gregory Smith wrote: > On 9/23/14, 1:21 AM, David Johnston wrote: > >> This patch should fix the round-to-zero issue. If someone wants to get >> rid of zero as a special case let them supply a separate patch for that >> "impro

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Tue, Sep 23, 2014 at 3:05 PM, Greg Stark wrote: > Fwiw I agree with TL2. The simplest, least surprising behaviour to explain > to users is to say we round to nearest and if that means we rounded to zero > (or another special value) we throw an error. We could list the minimum > value in pg_set

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Tue, Sep 23, 2014 at 1:30 AM, Tom Lane wrote: > David Johnston writes: > > My original concern was things that are rounded to zero now will not be > in > > 9.5 if the non-error solution is chosen. The risk profile is extremely > > small but it is not theoretically z

Re: [HACKERS] RLS feature has been committed

On Tue, Sep 23, 2014 at 9:14 AM, Robert Haas wrote: > On Tue, Sep 23, 2014 at 12:38 AM, David G Johnston > wrote: > > I'm of a mind to agree that this shouldn't have been committed...but I'm > not > > seeing where Stephen has done sufficient wrong to justify crucifixion. > > Especially since eve

Re: [HACKERS] RLS feature has been committed

On Tue, Sep 23, 2014 at 9:09 AM, Andres Freund wrote: > On 2014-09-22 21:38:17 -0700, David G Johnston wrote: > > Robert Haas wrote > > > It's difficult to imagine a more flagrant violation of process than > > > committing a patch without any warning and without even *commenting* > > > on the fac

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Tuesday, September 23, 2014, Tom Lane wrote: > David G Johnston > writes: > > Can you either change your mind back to this opinion you held last month > or > > commit something you find acceptable - its not like anyone would revert > > something you commit... :) > > Hey, am I not allowed to ch

Re: [HACKERS] PQputCopyEnd doesn't adhere to its API contract

On Tue, Sep 9, 2014 at 12:03 PM, Robert Haas wrote: > On Mon, Sep 8, 2014 at 6:20 PM, David G Johnston > wrote: > > On Mon, Sep 8, 2014 at 11:45 AM, Robert Haas [via PostgreSQL] <[hidden > > email]> wrote: > >> > >> On Thu, Sep 4, 2014 at 6:38 PM,

Re: [HACKERS] Re: [PATCH] parser: optionally warn about missing AS for column and table aliases

On Fri, Sep 5, 2014 at 6:27 PM, Marko Tiikkaja wrote: > On 2014-09-05 11:19 PM, David G Johnston wrote: > >> Marko Tiikkaja-4 wrote >> > > I probably couldn't mount a convincing defense of my opinion but at first >> blush I'd say we should pass on this. Not with prejudice - looking at the >> is

Re: [HACKERS] PQputCopyEnd doesn't adhere to its API contract

On Thu, Sep 4, 2014 at 5:13 PM, Robert Haas wrote: > On Thu, Sep 4, 2014 at 1:18 PM, David G Johnston > wrote: > > Specific observations would help though that is partly the idea - I've > been > > more focused on clarity and organization even if it requires deviating > from > > the current gener

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake wrote: > > On 09/02/2014 09:48 AM, Bruce Momjian wrote: > > As a case in point, EDB have spent quite a few man-years on their Oracle >>> compatibility layer; and it's still not a terribly exact match, according >>> to my colleagues who have looked

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 11:12 PM, Craig Ringer wrote: > On 09/02/2014 09:40 AM, David G Johnston wrote: > > Random thought as I wrote that: how about considering how pl/pgsql > > functionality can be generalize so that it is a database API that > > another language can call? In that way the serve

Re: [HACKERS] Built-in binning functions

On Sun, Aug 31, 2014 at 7:48 PM, Tom Lane wrote: > David G Johnston writes: > > Since "bucket" is the 'verb' here (in this specific case meaning "lookup > the > > supplied value in the supplied bucket definition") and "width" is a > modifier > > (the bucket specification describes an equal-width

Re: [HACKERS] Fixed redundant i18n strings in json

On Thu, Aug 7, 2014 at 5:53 PM, Tom Lane wrote: > David G Johnston writes: > > Tom Lane-2 wrote > >> Surely that was meant to read "invalid number OF arguments". The > errhint > >> is only charitably described as English, as well. I'd suggest something > >> like "Arguments of json_build_object

Re: [HACKERS] Re: Proposed changing the definition of decade for date_trunc and extract

On Fri, Aug 1, 2014 at 8:15 PM, Gavin Flower wrote: > On 02/08/14 12:32, David G Johnston wrote: > >> >> Any supporting arguments for 1-10 = 1st decade other than technical >> perfection? I guess if you use data around and before 1AD you care about >> this more, and rightly so, but given sound a

Re: [HACKERS] Is there a way to temporarily disable a index

On Fri, Jul 11, 2014 at 12:12 PM, Michael Banck wrote: > On Fri, Jul 11, 2014 at 11:07:21AM -0400, Tom Lane wrote: > > David G Johnston writes: > > > Benedikt Grundmann wrote > > >> That is it possible to tell the planner that index is off limits > > >> i.e. > > >> don't ever generate a plan usi

Re: [HACKERS] PL/pgSQL support to define multi variables once

On Fri, Jun 13, 2014 at 11:32 AM, Tom Lane wrote: > David G Johnston writes: > > Tom Lane-2 wrote > >> At the very least I think we should stay away from this syntax until > >> the SQL committee understand it better than they evidently do today. > >> I don't want to implement it and then get cau

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On Monday, June 9, 2014, Ian Barwick wrote: > > > On 09/06/14 14:47, David G Johnston wrote: > >> Ian Barwick wrote >> >>> Hi, >>> >>> The JDBC API provides the getGeneratedKeys() method as a way of >>> retrieving >>> primary key values without the need to explicitly specify the primary key >>> c

Re: [HACKERS] 9.4 release notes

On Mon, May 19, 2014 at 12:36 AM, Bruce Momjian wrote: > On Thu, May 15, 2014 at 06:08:47PM -0700, David G Johnston wrote: > > Some errors and suggestions - my apologizes for the format as I do not > have > > a proper patching routine setup. > > > > Patch Review - Top to Bottom (mostly, I think..

Re: [HACKERS] 9.4 release notes

On Mon, May 19, 2014 at 10:23 AM, Bruce Momjian wrote: > On Thu, May 15, 2014 at 06:08:47PM -0700, David G Johnston wrote: > > Some errors and suggestions - my apologizes for the format as I do not > have > > a proper patching routine setup. > > > > Sorry, let me address some items I skipped on y

Re: [HACKERS] DISCARD ALL (Again)

On Thursday, April 17, 2014, Joshua D. Drake wrote: > > On 04/17/2014 07:07 PM, David G Johnston wrote: > >> >> On 04/17/2014 05:24 PM, Tom Lane wrote: >> > On the whole I'm not sure this is something we ought to get into. >> > If you really need a fresh session, maybe you should st

Re: [HACKERS] polymorphic SQL functions has a problem with domains

Tom Lane-2 wrote > David Johnston < > polobo@ > > writes: >> Does something like: >> SELECT ($1 + $2)::$1%TYPE >> exist where you can explicitly cast to the type of the input argument? > > I don't think SQL-language functions have such a notatio

Re: [HACKERS] polymorphic SQL functions has a problem with domains

Tom Lane-2 wrote > Pavel Stehule < > pavel.stehule@ > > writes: >> I was informed about impossibility to use a polymorphic functions >> together >> with domain types > >> see > >> create domain xx as numeric(15); > >> create or replace function g(anyelement, anyelement) >> returns anyelement

Re: [HACKERS] PQputCopyData dont signal error

steve k wrote > Sorry I can't provide more information but I do appreciate your time. If > you can't get any further with it I understand and don't expect another > reply. For the benefit of others I'm reading this as basically you've found a better way to do this so you are no longer concerned

Re: [HACKERS] PQputCopyData dont signal error

steve k wrote > I started with this: > DBInsert_excerpts6_test_cpdlc.cpp > > > Can you point out to me where in that code you've followed this instruction from the documentation: "After successfully ca

Re: [HACKERS] PQputCopyData dont signal error

steve k wrote > Am I to understand then that I should expect no error feedback if copy > fails because of something like attempting to insert alphabetic into a > numeric? > > I apologize for my ignorance, but all my return codes were always > successful (PGRES_COMMAND_OK) even if nothing was cop

Re: [HACKERS] PQputCopyData dont signal error

steve k wrote > I realize this is an old thread, but seems to be the only discussion I can > find on this topic "I have a problem with PQputCopyData function. It > doesn't signal some error. " > > I am using from within a c++ program: > PQexec(m_pConn, "COPY... ...FROM stdin"), > >

Re: [HACKERS] psql \d+ and oid display

Bruce Momjian wrote > On Fri, Mar 28, 2014 at 03:53:32PM -0300, Fabrízio de Royes Mello wrote: >> On Fri, Mar 28, 2014 at 3:41 PM, Tom Lane < > tgl@.pa > > wrote: >> > >> > Bruce Momjian < > bruce@ > > writes: >> > > On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote: >> > >> I belie

Re: [HACKERS] History of WAL_LEVEL (archive vs hot_standby)

David Johnston wrote > > Noah Misch-2 wrote >> On Thu, Mar 27, 2014 at 03:06:02PM -0700, David Johnston wrote: >>> shamccoy wrote >>> > Hello. I've been doing some benchmarks on performance / size >>> differences >>> > between actions

Re: [HACKERS] History of WAL_LEVEL (archive vs hot_standby)

Noah Misch-2 wrote > On Thu, Mar 27, 2014 at 03:06:02PM -0700, David Johnston wrote: >> shamccoy wrote >> > Hello. I've been doing some benchmarks on performance / size >> differences >> > between actions when wal_level is set to either archive or hot_

Re: [HACKERS] History of WAL_LEVEL (archive vs hot_standby)

shamccoy wrote > Hello. I've been doing some benchmarks on performance / size differences > between actions when wal_level is set to either archive or hot_standby. > I'm not seeing a ton of difference. I've read some posts about > discussions as to whether this parameter should be simplified and

Re: [HACKERS] psql \d+ and oid display

Bruce Momjian wrote > When we made OIDs optional, we added an oid status display to \d+: > > test=> \d+ test >Table "public.test" >Column | Type | Modifiers | Storage | Stats target | Description > +-+---+-+

Re: [HACKERS] Minimum supported version of Python?

Peter Eisentraut-2 wrote > On 3/18/14, 11:22 AM, Andrew Dunstan wrote: >> Actually, if you run a buildfarm animal you have considerable control >> over what it tests. > > I appreciate that. My problem here isn't time or ideas or coding, but > lack of hardware resources. If I had hardware, I coul

Re: [HACKERS] Minimum supported version of Python?

Joshua D. Drake wrote > On 03/17/2014 07:31 PM, Peter Eisentraut wrote: >> >> On Sun, 2014-03-16 at 22:34 -0400, Tom Lane wrote: >>> Well, if you want to consider python 2.3 as supported, I have a >>> buildfarm >>> machine I am about to put online that has 2.3 on it. If I spin it up >>> with >>>

Re: [HACKERS] Minimum supported version of Python?

Peter Eisentraut-2 wrote > On Sat, 2014-03-15 at 20:55 -0400, Tom Lane wrote: >> Our documentation claims that the minimum Python version for plpython >> is 2.3. However, an attempt to build with that on an old Mac yielded >> a bunch of failures in the plpython_types regression test, > > It has f

Re: [HACKERS] Wiki Page Draft for upcoming release

Josh Berkus wrote > All, > > https://wiki.postgresql.org/wiki/20140320UpdateIssues > > I'm sure my explanation of the data corruption issue is not correct, so > please fix it. Thanks! I presume that because there is no way the master could have sent bad table data to the replication slaves that

Re: [HACKERS] Wiki Page Draft for upcoming release

I sent a post to -general with a much more detailed brain dump of my current understanding on this topic. The main point I'm addressing here is how to recover from this problem. Since a symptom of the problem is that pg_dump/restore can fail saying that (in some instances) the only viable restore

Re: [HACKERS] Planner hints in Postgresql

Atri Sharma wrote > On Mon, Mar 17, 2014 at 9:45 PM, Tom Lane < > tgl@.pa > > wrote: > >> David Johnston < > polobo@ > > writes: >> > Need to discuss the general "why" before any meaningful help on the >> "how" is >>

Re: [HACKERS] Planner hints in Postgresql

Atri Sharma wrote > On Mon, Mar 17, 2014 at 9:22 PM, Rajmohan C < > csrajmohan@ > > wrote: > >> I am implementing Planner hints in Postgresql to force the optimizer to >> select a particular plan for a query on request from sql input. I am >> having >> trouble in modifying the planner code. I wa

Re: [HACKERS] Is this a bug

fabriziomello wrote > On Thu, Mar 13, 2014 at 10:34 AM, Euler Taveira < > euler@.com > > > wrote: >> >> On 13-03-2014 00:11, Fabrízio de Royes Mello wrote: >> > Shouldn't the "ALTER" statements below raise an exception? >> > >> For consistency, yes. Who cares? I mean, there is no harm in resettin

Re: Bug: Fix Wal replay of locking an updated tuple (WAS: Re: [HACKERS] 9a57858f1103b89a5674f0d50c5fe1f756411df6)

Joshua D. Drake wrote > On 03/12/2014 06:15 PM, Tom Lane wrote: >> Robert Haas < > robertmhaas@ > > writes: >>> Discuss. >> >> This thread badly needs a more informative Subject line. >> > > No kidding. Or at least a link for goodness sake. Although the > pgsql-packers list wasn't all that help

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

Tom Lane-2 wrote > Unfortunately, while testing it I noticed that there's a potentially > fatal backwards-compatibility problem, namely that the "COPY n" status > gets printed on stdout, which is the same place that COPY OUT data is > going. While this isn't such a big problem for interactive use,

Re: [HACKERS] db_user_namespace a "temporary measure"

Andrew Dunstan wrote > On 03/11/2014 11:50 PM, Jaime Casanova wrote: >> On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane < > tgl@.pa > > 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 res

Re: [HACKERS] The case against multixact GUCs

Josh Berkus wrote > Hackers, > > In the 9.3.3 updates, we added three new GUCs to control multixact > freezing. This was an unprecented move in my memory -- I can't recall > ever adding a GUC to a minor release which wasn't backwards > compatibility for a security fix. This was a mistake. It pr

Re: [HACKERS] CREATE TYPE similar CHAR type

mohsencs wrote > I want use CREATE TYPE to create one type similar to char. > I want to when I create type, then my type behave similar to char: > > CREATE TABLE test (oneChar char); > > when I want insert one column with length>1 to it, so it gets this error: > ERROR: value too long for type ch

Re: [HACKERS] Equivalence Rules

Ali Piroozi wrote > Hi > Which equivalence rule from those are listed in > email's attachment are implemented in postgresql? > where are them? What do you mean by "where"? The various JOINS and UNION/INTERSECT/DIFFERENCE are all defined capabilities. SQL is not purely relational in nature so som

Re: [HACKERS] Simplified VALUES parameters

Leon Smith wrote > Hi, I'm the maintainer and a primary author of a postgresql client > library > for Haskell, called postgresql-simple, and I recently investigated > improving support for VALUES expressions in this library. As a result, > I'd > like to suggest two changes to postgresql: > > 1

Re: [HACKERS] Function sugnature with default parameter

salah jubeh wrote > Hello, > > I find default values confusing when a function is overloaded, below is an > example. > > > CREATE OR REPLACE FUNCTION default_test (a INT DEFAULT 1, b INT DEFAULT 1, > C INT DEFAULT 1) RETURNS INT AS > $$ >     BEGIN >         RETURN a+b+c; >     END; > $$ > LANG

Re: [HACKERS] 'dml' value for log_statement

Sawada Masahiko wrote > Hi all, > > Attaching patch provides new value 'dml' for log_statement. > Currently, The server logs modification statements AND data definition > statements if log_statement is set 'mod'. > So we need to set the 'all' value for log_statement and remove > unnecessary infor

[HACKERS] Re: Patch: regexp_matches variant returning an array of matching positions

Erik Rijkers wrote > On Wed, January 29, 2014 05:16, David Johnston wrote: >> >> How does this resolve in the patch? >> >> SELECT regexp_matches('abcabc','((a)(b)(c))','g'); >> > > With the patch: > > testdb=# SELECT reg

[HACKERS] Re: Patch: regexp_matches variant returning an array of matching positions

Alvaro Herrera-9 wrote > Björn Harrtell wrote: >> I've written a variant of regexp_matches called regexp_matches_positions >> which instead of returning matching substrings will return matching >> positions. I found use of this when processing OCR scanned text and >> wanted >> to prioritize matches

[HACKERS] Re: Fixing bug #8228 ("set-valued function called in context that cannot accept a set")

Tom Lane-2 wrote > David Johnston < > polobo@ > > writes: >> The whole "varchar/varchar(30)" discrepancy is bothersome and since the >> example forces a function-call via the use of "lower(...)", and doesn't >> test >> the non-func

[HACKERS] Re: Fixing bug #8228 ("set-valued function called in context that cannot accept a set")

David Johnston wrote > > Tom Lane-2 wrote >> I kinda forgot about this bug when I went off on vacation: >> http://www.postgresql.org/message-id/ >> E1UnCv4-0007oF-Bo@.postgresql > > Just to clarify: > > This patch will cause both executions of the example

[HACKERS] Re: Fixing bug #8228 ("set-valued function called in context that cannot accept a set")

Tom Lane-2 wrote > I kinda forgot about this bug when I went off on vacation: > http://www.postgresql.org/message-id/ > E1UnCv4-0007oF-Bo@.postgresql Just to clarify: This patch will cause both executions of the example query to fail with the "set-valued function..." error. Also, the reason the

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier

Andres Freund-3 wrote > On 2014-01-06 09:12:03 -0800, Mark Dilger wrote: >> The reason I was going to all the trouble of creating >> chrooted environments was to be able to replicate >> clusters that have tablespaces.  Not doing so makes >> the test code simpler at the expense of reducing >> test c

Re: [HACKERS] trailing comment ghost-timing

Andreas Karlsson wrote > On 12/24/2013 02:05 AM, Erik Rijkers wrote: >> With \timing on, a trailing comment yields a timing. >> >> # test.sql >> select 1; >> >> /* >> select 2 >> */ >> >> $ psql -f test.sql >> ?column? >> -- >> 1 >> (1 row) >> >> Time: 0.651 ms >> Time: 0.089 ms

Re: [HACKERS] array_length(anyarray)

Marko Tiikkaja-4 wrote > On 2013-12-18 22:32, Andrew Dunstan wrote: >> You're not really free to assume it - you'll need an exception handler >> for the other-than-1 case, or your code might blow up. >> >> This seems to be codifying a bad pattern, which should be using >> array_lower() and array_up

[HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

MauMau wrote > From: "David Johnston" < > polobo@ > > >>> 5. FATAL: terminating walreceiver process due to administrator command >>> 6. FATAL: terminating background worker \"%s\" due to administrator >>> command >> 5 an

[HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

MauMau wrote > From: "Tom Lane" < > tgl@.pa > > >> There is no enthusiasm for a quick-hack solution here, and most people >> don't actually agree with your proposal that these errors should never >> get logged. So no, that is not happening. You can hack your local >> copy that way if you like o

[HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

David Johnston wrote > > MauMau wrote >> From: "Tom Lane" < >> tgl@.pa >> > >>> There is no enthusiasm for a quick-hack solution here, and most people >>> don't actually agree with your proposal that these errors should never &g

[HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

MauMau wrote > From: "Tom Lane" < > tgl@.pa > > >> There is no enthusiasm for a quick-hack solution here, and most people >> don't actually agree with your proposal that these errors should never >> get logged. So no, that is not happening. You can hack your local >> copy that way if you like o

Re: [HACKERS] WITHIN GROUP patch

Andrew Gierth wrote >> "Tom" == Tom Lane < > tgl@.pa > > writes: > > >> Please don't object that that doesn't look exactly like the syntax > >> for calling the function, because it doesn't anyway --- remember > >> you also need ORDER BY in the call. > > Tom> Actually, now that I think o

Re: [HACKERS] RFC: programmable file format for postgresql.conf

Álvaro Hernández Tortosa wrote >> Note that you are not required to maintain your configuration data in a >> postgresql.conf-formatted file. You can keep it anywhere you like, GUI >> around in it, and convert it back to the required format. Most of the > > I think it is not a very good i

Re: [HACKERS] WITHIN GROUP patch

Tom Lane-2 wrote > Further questions about WITHIN GROUP: > > I believe that the spec requires that the "direct" arguments of an inverse > or hypothetical-set aggregate must not contain any Vars of the current > query level. They don't manage to say that in plain English, of course, > but in the

[HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

Tom Lane-2 wrote > "MauMau" < > maumau307@ > > writes: >> Shouldn't we lower the severity or avoiding those messages to server log? > > No. They are FATAL so far as the individual session is concerned. > Possibly some documentation effort is needed here, but I don't think > any change in the c

Re: [HACKERS] Add full object name to the tag field

Robert Haas wrote > On Mon, Dec 2, 2013 at 9:49 AM, Asit Mahato < > rigid.asit@ > > wrote: >> Hi all, >> >> I am a newbie. I am unable to understand the to do statement given below. >> >> Add full object name to the tag field. eg. for operators we need >> '=(integer, >> integer)', instead of just

[HACKERS] Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

Robert Haas wrote >> >> Issuing > > ROLLBACK > > outside of a transaction >> block has the sole effect of emitting a warning. > > Sure, that sounds OK. > > ...Robert +1 for: Issuing ROLLBACK outside of a transaction block has no effect except emitting a warning. In all of these

Re: [HACKERS] bytea_ouput = escape vs encode(byte, 'escape')

Jim Nasby-2 wrote > I'm wondering why bytes_output = escape produces different output than > encode(byte, 'escape') does. Is this intentional? If so, why? > > cnuapp_prod@postgres=# select e'\r'::bytea AS cr, e'\n'::bytea AS lf; > cr | lf > --+-- > \x0d | \x0a > (1 row) > > cnuapp_

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

Josh Berkus wrote > On 11/25/2013 03:36 PM, David Johnston wrote: >> Doh! >> >> IF / THEN / ELSE / ENDIF (concept, not syntax) >> >> That also does help to reinforce the point being made here... >> >> David J. > > What point?

[HACKERS] Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

Bruce Momjian wrote >> >> - Issuing > > ABORT > > when not inside a transaction does >> >> - no harm, but it will provoke a warning message. >> >> + Issuing > > ABORT > > outside of a transaction block has no effect. >> >> >> >> Those things are not the same. >> >> > Uh, I ended up

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

Andrew Dunstan wrote > On 11/25/2013 06:13 PM, David Johnston wrote: >> >> A side observation: why does "DECLARE" not require a block-end keyword >> but >> instead "BEGIN" acts as effectively both start and end? BEGIN, IF, FOR, >> etc... all c

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

Mark Kirkwood-2 wrote > Postgres supports many procedural languages (e.g plperl, plpython) and all > these have different > grammar rules from SQL - and from each other. We can't (and shouldn't) > try altering them to be similar to SQL - it would defeat the purpose of > providing a procedural en

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

AK wrote > Kevin, > > I do see your logic now, but this thing is a common mistake - it means > that this seems counter-intuitive to some people. What would happen if we > applied Occam's razor and just removed this rule? > > All existing code would continue to work as is, and we would have one le

Re: [HACKERS] Why is UPDATE with column-list syntax not implemented

AK wrote > 9.3 documentation says: > > According to the standard, the column-list syntax should allow a list of > columns to be assigned from a single row-valued expression, such as a > sub-select: > > UPDATE accounts SET (contact_last_name, contact_first_name) = > (SELECT last_name, first_na

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Tom Lane-2 wrote > We could conceivably say that we'll implicitly UNNEST() if the function > returns array, and not otherwise --- but that seems pretty inconsistent > and surprise-making to me. The use-cases for putting a scalar array returning function call into a TABLE construct, and NOT wantin

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Tom Lane-2 wrote > Andrew Gierth < > andrew@.org > > writes: >> "Tom" == Tom Lane < > tgl@.pa > > writes: >> Tom> and this would result in producing the array elements as a table >> Tom> column. There is nothing in there about a function returning >> Tom> set. > >> In the spec, there is no

  1   2   >