Re: [HACKERS] merging some features from plpgsql2 project

> >> Related to that, I suspect we could add better support to existing >> commands for at least some of these things. For example, SELECT ... INTO >> NOMULTI (instead of STRICT) to indicate that multiple rows are an error but >> missing data is > > > Another flag into NOMULTI can be solution too.

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-08 3:27 GMT+01:00 Jim Nasby : > On 1/5/17 11:36 AM, Merlin Moncure wrote: > >> The C language really should be considered the gold standard here. >> Changes did have to be made, like getting rid of the notoriously >> broken and insecure gets(), but they were made

Re: [HACKERS] merging some features from plpgsql2 project

> > >> >> BTW, I do wish you could change the label of the scope that arguments >> went into, so that you could use that label to refer to function >> parameters. If we allowed that it'd perhaps be the best of both worlds: >> you'd be guaranteed access to all auto variables and parameters, and

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

> AFAICS, what Ryan is after would be better served by a separate tool that > would produce a "diff" of the two tables' schemas. Related to the other idea of seeing the problems that exist in all the > columns (instead of one column at a time), I think it'd be reasonable to > have a SRF that spit

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-08 3:31 GMT+01:00 Jim Nasby : > On 1/7/17 5:39 AM, Pavel Stehule wrote: > >> >> I checked current implementation of FOUND variable. If we introduce new >> auto variable ROW_COUNT - exactly like FOUND, then it doesn't introduce >> any compatibility break. >> > >

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-08 3:39 GMT+01:00 Jim Nasby : > On 1/7/17 2:06 AM, Pavel Stehule wrote: > >> >> SELECT t1 := c1, t2 := c2, ... >> >> - it can be PostgreSQL specific syntax - full control over design >> - maximally robust against typo >> - long syntax, but for short syntax

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

Jim Nasby writes: > On 1/6/17 2:45 PM, Tom Lane wrote: >> While I was checking the patch to verify that it didn't change any >> behavior, I noticed that it did, and there's a pre-existing bug here: >> pltcl_build_tuple_result is applying utf_e2u to the Tcl_GetString

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-08 4:11 GMT+01:00 Jim Nasby : > On 1/7/17 8:53 PM, Tom Lane wrote: > >> If FOUND were declared at an outer scoping level such that any >> user-created declaration overrode the name, then we could do likewise >> for other auto variables and not fear compatibility

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-08 3:53 GMT+01:00 Tom Lane : > Jim Nasby writes: > > On 1/7/17 5:39 AM, Pavel Stehule wrote: > >> I checked current implementation of FOUND variable. If we introduce new > >> auto variable ROW_COUNT - exactly like FOUND, then it doesn't

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

On 1/6/17 2:45 PM, Tom Lane wrote: The only thing that seems significant is that we'd change the SQLSTATE for the "odd number of list items" error: pltcl_trigger_handler has (errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED), errmsg("trigger's return list must have

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

> Perhaps the ERROR message should remain as is, and a DETAIL or HINT line > could be emitted with the entire column definition (or close to it)? > > I'm open to this option as well. The only parts I really care about are the type and the NOT NULL, since those are the ones that will give you an

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 1/6/17 7:21 PM, Bruce Momjian wrote: I don't think anyone is arguing that these API breakages are cost-free, but I think long-term, the costs are minor compared to the clean API we provide to users. Except in this case we can provide a clean new API without gratuitously breaking the old

Re: [HACKERS] pg_background contrib module proposal

On 12/22/16 4:30 PM, Robert Haas wrote: On Thu, Dec 22, 2016 at 4:41 PM, Jim Nasby wrote: On 12/22/16 4:20 AM, amul sul wrote: • pg_background_detach : This API takes the process id and detach the background process. Stored worker's session is not dropped until this

Re: [HACKERS] merging some features from plpgsql2 project

On 1/7/17 8:53 PM, Tom Lane wrote: If FOUND were declared at an outer scoping level such that any user-created declaration overrode the name, then we could do likewise for other auto variables and not fear compatibility breaks. Currently, though, we don't seem to be quite there: it looks like

Re: [HACKERS] ICU integration

On Tue, Dec 27, 2016 at 6:50 PM, Peter Eisentraut wrote: > I don't have much experience with the abbreviated key stuff. I have > filled in what I think should work, but it needs detailed review. Thanks. It occurs to me that the comparison caching stuff added

Re: [HACKERS] [WIP]Vertical Clustered Index (columnar store extension)

On 12/29/16 9:55 PM, Haribabu Kommi wrote: The tuples which don't have multiple copies or frozen data will be moved from WOS to ROS periodically by the background worker process or autovauum process. Every column data is stored separately in it's relation file. There is no transaction

Re: [HACKERS] merging some features from plpgsql2 project

Jim Nasby writes: > On 1/7/17 5:39 AM, Pavel Stehule wrote: >> I checked current implementation of FOUND variable. If we introduce new >> auto variable ROW_COUNT - exactly like FOUND, then it doesn't introduce >> any compatibility break. > Except it would break every

Re: [HACKERS] merging some features from plpgsql2 project

On 1/7/17 2:06 AM, Pavel Stehule wrote: SELECT t1 := c1, t2 := c2, ... - it can be PostgreSQL specific syntax - full control over design - maximally robust against typo - long syntax, but for short syntax can be used SELECT c1,c2,c3, .. INTO STRICT recvar I don't think overloading a SQL

Re: [HACKERS] merging some features from plpgsql2 project

On 1/7/17 5:39 AM, Pavel Stehule wrote: I checked current implementation of FOUND variable. If we introduce new auto variable ROW_COUNT - exactly like FOUND, then it doesn't introduce any compatibility break. Except it would break every piece of code that had a row_count variable, though I

Re: [HACKERS] merging some features from plpgsql2 project

On 1/5/17 11:36 AM, Merlin Moncure wrote: The C language really should be considered the gold standard here. Changes did have to be made, like getting rid of the notoriously broken and insecure gets(), but they were made very, very slowly and unobtrusively. For those not familiar... how did

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

Ashutosh Bapat writes: > On Tue, Jan 3, 2017 at 5:57 PM, Rahila Syed wrote: >> Are you suggesting extending the patch to include coercing from unknown to >> text for all possible cases where a column of unknown type is being created? > I

[HACKERS] Allow controlling location of tmp_install

While running a couple of parallel make (install)check-worlds I was surprised to see my system load at 5x what I'd think it'd be. Looking at CPU % consumption it turns out this was because mds (the OS X indexing service) and a few other things were going bonkers. That's because they were all

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On 1/5/17 12:55 PM, Jonathon Nelson wrote: Attached please find a patch for PostgreSQL 9.4 which changes the maximum amount of data that the wal sender will send at any point in time from the hard-coded value of 128KiB to a user-controllable value up to 16MiB. It has been primarily tested under

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On 1/6/17 12:24 AM, Ryan Murphy wrote: I don't actually believe this to indicate a problem though - I think perhaps there's a problem with this test, or with how I am running it. The only diff was that when it (correctly) complained of a nonexistent database, it referred to my username that I

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

On 1/7/17 1:16 PM, Ryan Murphy wrote: No, and TBH I would vote strongly against including that much detail in this error message anyway. That info could be indefinitely long, and it's not especially relevant to the stated error condition --- for example, the presence of

Re: [HACKERS] Replication/backup defaults

On 1/5/17 2:50 PM, Tomas Vondra wrote: Ultimately, the question is whether the number of people running into "Hey, I can't take pg_basebackup or setup a standby with the default config!" is higher or lower than number of people running into "Hey, CREATE TABLE + COPY is slower now!" I'm betting

Re: [HACKERS] pg_stat_activity.waiting_start

On 1/7/17 12:41 PM, Joel Jacobson wrote: On Sat, Jan 7, 2017 at 3:25 AM, Greg Stark wrote: What users need to know is in aggregate how much of the time the database is spending working on their queries is going into different states. This is a separate feature idea, but I

Re: [HACKERS] pg_stat_activity.waiting_start

On 12/28/16 10:26 PM, Robert Haas wrote: On Wed, Dec 28, 2016 at 1:06 PM, Tom Lane wrote: Jim Nasby writes: On 12/28/16 11:25 AM, Tom Lane wrote: The idea of just capturing the wait start for heavyweight locks, and not other lock types, still

Re: [HACKERS] increasing the default WAL segment size

On 1/5/17 5:38 AM, Beena Emerson wrote: On Tue, Jan 3, 2017 at 2:53 AM, Jim Nasby > wrote: General comments: There was some discussion about the impact of this on small installs, particularly around min_wal_size. The concern

Re: [HACKERS] increasing the default WAL segment size

On 1/4/17 10:03 PM, David Rowley wrote: I recall taht pow(x, 2) and x * x result usually in the same assembly code, but pow() can never be more optimal than a simple multiplication. So I'd think that it is wiser to avoid it in this code path. Documentation is missing for the new replication

Re: [HACKERS] Increase pltcl test coverage

On 1/6/17 2:17 PM, Tom Lane wrote: Jim Nasby writes: On 10/31/16 3:24 PM, Jim Nasby wrote: This patch increases test coverage for pltcl, from 70% to 83%. Aside from that, the work on this uncovered 2 new bugs (the trigger return one I just submitted, as well as a bug

Re: [HACKERS] proposal: session server side variables (fwd)

On Thu, Jan 5, 2017 at 11:45:24AM +0100, Fabien COELHO wrote: > > I must tweak my mail client configuration...> > > >>>Good. So we seem to agree that GUCS are transactional? > > > >I'm surprised, I never knew this. > > I must admit

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

On 01/07/2017 11:05 PM, Tom Lane wrote: > Vik Fearing writes: >> On 01/07/2017 08:15 PM, Tom Lane wrote: >>> No, and TBH I would vote strongly against including that much detail in >>> this error message anyway. That info could be indefinitely long, and it's >>> not

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

Vik Fearing writes: > On 01/07/2017 08:15 PM, Tom Lane wrote: >> No, and TBH I would vote strongly against including that much detail in >> this error message anyway. That info could be indefinitely long, and it's >> not especially relevant to the stated error condition ---

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

On 01/07/2017 08:15 PM, Tom Lane wrote: > Ryan Murphy writes: >> I was hoping for >> user=# alter table temp inherit entity; >> ERROR: child table is missing column "id" uuid default uuid_generate_v1mc() >> Is there an easy way to get the string that includes all those

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

> No, and TBH I would vote strongly against including that much detail in > this error message anyway. That info could be indefinitely long, and it's > not especially relevant to the stated error condition --- for example, the > presence of a default is *not* relevant to whether the column

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

Ryan Murphy writes: > So I tried using format_type_with_typemod() thinking that the "typemod > info" meant things like NOT NULL, DEFAULT etc. No, it means atttypmod, which stores info like the max length for varchar(n). > when I was hoping for > user=# alter table temp

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

> Thanks Tom, I'll redo the patch using one of those, and get back to you > guys. > > So I tried using format_type_with_typemod() thinking that the "typemod info" meant things like NOT NULL, DEFAULT etc. It builds and includes the plain type but not all that stuff. E.g. user=# alter table temp

Re: [HACKERS] Replication/backup defaults

On 1/7/17 6:23 AM, Magnus Hagander wrote: > In the build farm, I have found 6 critters that do not end up with the > 100/128MB setting: sidewinder, curculio, coypu, brolga, lorikeet, > opossum. I wonder what limitations initdb is bumping against. > > > Since you lookeda t the data

Re: [HACKERS] pg_stat_activity.waiting_start

On Sat, Jan 7, 2017 at 3:25 AM, Greg Stark wrote: > What users need to know is in aggregate how much of the time the > database is spending working on their queries is going into different > states. This is a separate feature idea, but I think it's really valuable as well. Maybe

Re: [HACKERS] Shrink volume of default make output

On Mon, Jan 2, 2017 at 03:37:04PM -0600, Jim Nasby wrote: > The recent thread about compiler warnings got me thinking about how it's > essentially impossible to notice warnings with default make output. Perhaps > everyone just uses make -s by default, though that's a bit annoying since > you get

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

> The approved way to do this is with format_type_be(), or > format_type_with_typemod() if you want to include typmod info, which > I think you probably do for the intended use-case. > > regards, tom lane > Thanks Tom, I'll redo the patch using one of those, and get back

Re: [HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

Ryan Murphy writes: > The attached patch is my initial attempt at adding the type, making the > error message read e.g.: > ERROR: child table is missing column "name" text "... column "name" of type text", perhaps? Does not read very nicely as is. > I'm sure it needs

Re: [HACKERS] [WIP]Vertical Clustered Index (columnar store extension)

On Fri, Dec 30, 2016 at 02:55:39PM +1100, Haribabu Kommi wrote: > > Hi All, > > Fujitsu was interested in developing a columnar storage extension with minimal > changes the server backend. > > The columnar store is implemented as an extension using index access methods. > This can be easily

[HACKERS] Adding type info etc for inheritance errmsg: "child table is missing column ..."

Hey Postgres team! I've been gleefully using the inheritance feature of Postgres for the last 6 months or so, and it's really great! I especially like how easily you can ALTER TABLE foo INHERIT bar, and get helpful error messages about what columns need to be there before the inherit can take

Re: [HACKERS] Incorrect XLogRegisterBuffer flag for revmapbuf in brin

Added to next commitfest for tracking. I should've done it earlier. -- Thanks & Regards, Kuntal Ghosh EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Teaching query_planner to handle multiple sort orders?

> "Tom" == Tom Lane writes: >> Of course there is one good solution, which is to have query_planner >> take a set of acceptable output sort orders rather than just a >> single one. >> How wild an idea is this? Tom> It's been on my to-do list for years, see e.g.

Re: [HACKERS] Teaching query_planner to handle multiple sort orders?

Andrew Gierth writes: > So in the grouping sets patch post, I said: > There is one current weakness which I don't see a good solution for: > the planner code still has to pick a single value for group_pathkeys > before planning the input path. This means that we

Re: [HACKERS] pg_stat_activity.waiting_start

On Sat, Jan 7, 2017 at 01:25:08PM +, Greg Stark wrote: > I would actually argue the reverse of the above proposal would be more > useful. What we need are counts of how often LWLocks take longer than, > say, 50ms and for shorter waits we need to know how long. Perhaps not > precisely for

[HACKERS] Teaching query_planner to handle multiple sort orders?

So in the grouping sets patch post, I said: >> There is one current weakness which I don't see a good solution for: >> the planner code still has to pick a single value for group_pathkeys >> before planning the input path. This means that we sometimes can't >> choose a minimal set of sorts,

Re: [HACKERS] pg_background contrib module proposal

On Sat, Jan 7, 2017 at 2:06 PM, Andrew Borodin wrote: > Hi! > > 2017-01-07 11:44 GMT+05:00 amul sul : > >> Changes: >> 1. pg_background_launch renamed to pg_background_start >> 2. pg_background_detach renamed to pg_background_close >> 3. Added new api to

Re: [HACKERS] pg_stat_activity.waiting_start

On 6 January 2017 at 02:59, Bruce Momjian wrote: > > Agreed. No need in adding overhead for short-lived locks because the > milli-second values are going to be meaningless to users. I would be > happy if we could find some weasel value for non-heavyweight locks. For what it's

Re: [HACKERS] Make pg_basebackup -x stream the default

On Sat, Jan 7, 2017 at 12:04 AM, Magnus Hagander wrote: > On Wed, Jan 4, 2017 at 10:43 AM, Magnus Hagander > wrote: >> Meh, just as I was going to respond "committed" I noticed this second >> round of review comments. Apologies, pushed without that. >>

Re: [HACKERS] merging some features from plpgsql2 project

> > > * EXECUTE and FOUND - this is incompatible change, extra check can be used > (test on unset variable). I see solution in leaving FOUND variable and > introduction of some new without this issue - ROW_COUNT maybe (this is > another possible incompatible change, but with higher benefit - maybe

Re: [HACKERS] Replication/backup defaults

On Sat, Jan 7, 2017 at 1:27 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 1/5/17 12:01 PM, Andres Freund wrote: > > On 2017-01-05 08:38:32 -0500, Peter Eisentraut wrote: > >> I also suggest making the defaults for both 20 instead of 10. That > >> leaves enough room that

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Sat, Jan 7, 2017 at 12:31 AM, Michael Paquier wrote: > On Fri, Jan 6, 2017 at 11:07 PM, Magnus Hagander > wrote: > > A few further notes: > > Thanks for the review. > > > You are using the filemode to gzopen and the mode_compression variable to

Re: [HACKERS] pgbench - allow to store select results into variables

Hello Tom, Please look at changing \into to be a SQL-command-ending backslash command as we previously discussed. Done. There are two variants: \gset & \gcset for compound (end SQL query, set variables, but do not end command, so that several settings are allowed in a compound command, a

Re: [HACKERS] pg_background contrib module proposal

Hi! 2017-01-07 11:44 GMT+05:00 amul sul : > Changes: > 1. pg_background_launch renamed to pg_background_start > 2. pg_background_detach renamed to pg_background_close > 3. Added new api to display previously launch background worker & its > result count waiting to be read.

Re: [HACKERS] autonomous transactions

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Here’s review of Background Sessions v2 patch. ===Purpose===

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-03 17:57 GMT+01:00 Jim Nasby : > On 1/2/17 1:51 PM, Pavel Stehule wrote: > >> 1) Neither is enabled by default, so 90% of users have no idea they >> exist. Obviously that's an easy enough fix, but... >> >> We can strongly talk about it - there can be a