Re: [HACKERS] proposal: schema variables

" Although the syntax of CREATE TEMPORARY TABLE resembles that of the SQL standard, the effect is not the same. In the standard, temporary tables are defined just once and automatically exist (starting with empty contents) in every session that needs them. PostgreSQL instead requires each

Re: [HACKERS] proposal: schema variables

Pavel, I can imagine, so DECLARE command will be introduced as short cut for CREATE TEMP VARIABLE, but in this moment I would not to open this topic. I afraid of bikeshedding and I hope so CREATE TEMP VAR is anough. Language is important because language stays. You choice of syntax will

Re: [HACKERS] MERGE SQL Statement for PG11

via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx=9.8.79=10.12.6=email_footer_2] On Fri, Oct 27, 2017 at 2:42 PM, Peter Geoghegan wrote: On Fri, Oct 27, 2017 at 2:13 PM, srielau wrote: > While the standard may not require a unique index for the ON clause

Re: [HACKERS] generated columns

/blogs/SQLTips4DB2LUW/entry/expression_generated_columns?lang=en> Cheers Serge Rielau salesforce.com

Re: [HACKERS] Silent bug in transformIndexConstraint

Never mind. I take that back. The problem is not in community code. Cheers Serge -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Silent bug in transformIndexConstraint

In parse_utilcmd.c: transformIndexConstraint() resides the following piece of code: /* * For UNIQUE and PRIMARY KEY, we just have a list of column names. * * Make sure referenced keys exist. If we are making a PRIMARY KEY index, * also make sure they are NOT NULL, if possible. (Although we

Re: [HACKERS] CTE inlining

On Tue, May 9, 2017 at 12:22 PM, David G. Johnston wrote: On Tue, May 9, 2017 at 12:15 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com [peter.eisentr...@2ndquadrant.com] > wrote: On 5/5/17 08:43, David Rowley wrote: > How about we get the ball rolling on this

Re: [HACKERS] CTE inlining

In my past life when I was faced with such debates I argued that the number of customers We are hoping to attract in the future is much bigger than the ones we risk offending. Doesn't mean I wanted to piss everyone off. Just that I didn't want to be held hostage by history. Cheers Serge PS: On

Re: [HACKERS] CTE inlining

I haven't been keeping close tabs either, but surely we still have to have the optimization fence in (at least) all these cases: * CTE contains INSERT/UPDATE/DELETE * CTE contains SELECT FOR UPDATE/SHARE (else the set of rows that get locked might change) * CTE contains volatile functions I'm

Re: [HACKERS] CTE inlining

plicating the CTE to push distinct operators from different consumers. Again this can only be done if there are no mutators or non deterministic operators. To summarize: big +1 to preserve the existing behavior with MATERIALIZE and to set CTE’s free by default with the onus on the optimizer to pr

Re: [HACKERS] Cached plans and statement generalization

via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx=9.4.52=10.11.6=email_footer_2] On Tue, Apr 25, 2017 at 3:48 PM, Doug Doole wrote: It's not always that simple, at least in postgres, unless you disregard search_path. Consider e.g. cases like CREATE SCHEMA a;

Re: [HACKERS] Cached plans and statement generalization

> On Apr 25, 2017, at 1:37 PM, Konstantin Knizhnik > wrote: >> >> SELECT ‘hello’::CHAR(10) || ‘World’, 5 + 6; >> >> You can substitute ‘hello’, ‘World’, 5, and 6. But not 10. > > I am substituting only string literals. So the query above will be > transformed to

Re: [HACKERS] Cached plans and statement generalization

On Tue, Apr 25, 2017 at 9:45 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: On 25.04.2017 19:12, Serge Rielau wrote: On Apr 25, 2017, at 8:11 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru [k.knizh...@postgrespro.ru] > wrote: Another problem is caused by using integ

Re: [HACKERS] Cached plans and statement generalization

author of the SQL left the remaining literals in on purpose. A follow up feature would be to formalize different flavors of peeking. I.e. can you produce a generic plan, but still recruit the initial set of bind values/substituted literals to dos costing? Cheers Serge Rielau Salesforce.com

Re: [HACKERS] Fast Default WIP patch for discussion

, Apr 5, 2017 at 4:47 PM, Andres Freund <and...@anarazel.de> wrote: Hi Serge, On 2016-10-28 08:28:11 -0700, Serge Rielau wrote: > Time for me to dig into that then. Are you planning to update your POC at some point? This'd be a very welcome improvement. Regards, Andres

Re: [HACKERS] Packages: Again

> > Still I little bit afraid about nesting - Postgres allows function > overloading with specific mechanism of selecting called function. Sometimes > it is problematic now, and the this structure is flat. > > I like a idea of more close relation between function and schema. This means >

Re: [HACKERS] Packages: Again

> DB2 propose using schemas instead packages > > https://www.ibm.com/developerworks/data/library/techarticle/dm-0711zubiri/ > [https://www.ibm.com/developerworks/data/library/techarticle/dm-0711zubiri/] > That article by Adriana is 6 years ago and was written actually while we > implemented

Re: [HACKERS] Packages: Again

On Fri, Jan 13, 2017 at 4:24 PM, Peter Geoghegan <p...@heroku.com> wrote: On Fri, Jan 13, 2017 at 3:44 PM, Serge Rielau <se...@rielau.com> wrote: > And sometimes the community DOES go its own way rather than implementing the > standard. For example by rejecting the MERGE

Re: [HACKERS] Packages: Again

On Fri, Jan 13, 2017 at 2:46 PM, Kevin Grittner <kgri...@gmail.com> wrote: On Fri, Jan 13, 2017 at 12:35 PM, Serge Rielau <se...@rielau.com> wrote: > Yes my proposal to nest schemata is “radical” and this community > is not falling into that camp. > But there

Re: [HACKERS] Packages: Again

On Fri, Jan 13, 2017 at 12:45 PM, Pavel Stehule wrote: show patch and show a advantages against schema, please. I have tried to describe the advantage. If the community doesn’t agree, that’s fine. I do not see how expending the effort of back porting a patch (and

Re: [HACKERS] Packages: Again

> On Jan 13, 2017, at 11:11 AM, Pavel Stehule wrote: > > With Postgres we should to think much more about other PL - there is not only > PL/pgSQL. So any what we create should be available for any PL. Our PLpgSQL > is based on total different technology design - so

Re: [HACKERS] Packages: Again

> On Jan 13, 2017, at 10:23 AM, Pavel Stehule wrote: > > I have not clean feeling from this - I am pretty sure so I am afraid > schizophrenic between MODULES, SCHEMAS. Nested schemas increase complexity > of searching complexity and breaks a logic

Re: [HACKERS] Packages: Again

to at least port our module code to the community codebase. We can take it from there. Cheers Serge Rielau Salesforce.com

Re: [HACKERS] missing optimization - column <> column

Actually there are lots of things that can be done with this sort of theorem proving. And NULL is a plenty good answer for a filter, just not for a check constraint. Amongst them INSERT through UNION ALL for symmetric views which can be handy for FDW partitioned tables. One such implementation

Re: [HACKERS] Fast Default WIP patch for discussion

> On Oct 28, 2016, at 5:46 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Fri, Oct 21, 2016 at 7:15 PM, Serge Rielau <se...@rielau.com> wrote: >> Some key design points requiring discussion: >> 1. Storage of the “exist” (working name) default >>

Re: [HACKERS] Fast Default WIP patch for discussion

and a wiki link. Should I push the patch to some branch, if so which repository? Thanks Serge The form does ask for a git link rather > On Oct 26, 2016, at 8:51 AM, Euler Taveira <eu...@timbira.com.br> wrote: > > On 26-10-2016 12:43, Serge Rielau wrote: >> Posting to this grou

Re: [HACKERS] Fast Default WIP patch for discussion

:15 PM, Serge Rielau <se...@rielau.com> wrote: > ... > > Some key design points requiring discussion: > 1. Storage of the “exist” (working name) default >Right now the patch stores the default value in its binary form as it > would be in the tuple into a BYTEA. >

[HACKERS] Fast Default WIP patch for discussion

As promised and requested find attached a work in progress patch for fast defaults.This is my first patch, I hope I used the right format…..The premise of the feature is to avoid a table rewrite when adding a column with a default.This is done by remembering the default value in pg_attribute

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

This feature was added in DB2 year ago. AFAIK it was not very successful. Regular compression techniques proved serve a broader and purpose and save more space. http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.dbobj.doc/doc/c0056482.html

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

> On Oct 6, 2016, at 9:20 AM, Tom Lane wrote: > > Vitaly Burovoy writes: >> But what I discover for myself is that we have pg_attrdef separately >> from the pg_attribute. Why? > > The core reason for that is that the default expression needs to be

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

> On Oct 6, 2016, at 9:01 AM, Tom Lane wrote: > > BTW, it also occurs to me that there are going to be good implementation > reasons for restricting it to be a hard constant, not any sort of > expression. We are likely to need to be able to insert the value in > low-level

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

> On Oct 6, 2016, at 5:25 AM, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > > On 10/6/16, Simon Riggs <si...@2ndquadrant.com> wrote: >> On 6 October 2016 at 04:43, Serge Rielau <se...@rielau.com> wrote: >>>>> Or should I compose some sort of a

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

> On Oct 5, 2016, at 5:52 PM, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > > On 10/5/16, Serge Rielau <se...@rielau.com> wrote: >> I want to point out as a minor "extension" that there is no need for the >> default to be immutable. It is m

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

e limited to immutable(?) default expressions to comply with existing behavior, which matches SQL Servers. My current patch does not restrict that and thusly falsely "fills in" the same value for all rows. Cheers Serge Rielau Salesforce.com

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

be immutable. It is merely required that the default is evaluate at time of ADD COLUMN and then we remember the actual value for the exist default, rather than the parsed expression as we do for the “current” default. Need a better name for the concept, since evidently this name isn't conveying the idea. By all means. Got anything in mind? Cheers Serge Rielau

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

On Wed, Oct 5, 2016 at 3:23 PM, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: On 10/5/16, Andres Freund <and...@anarazel.de> wrote: > On 2016-10-05 11:58:33 -0700, Serge Rielau wrote: >> Dear Hackers, >> I’m working on a patch that expands PG’s ability to add co

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

On Wed, Oct 5, 2016 at 2:45 PM, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: On 10/5/16, Serge Rielau <se...@rielau.com> wrote: > Dear Hackers, > > I’m working on a patch that expands PG’s ability to add columns to a table > without a table rewrite (i.e. at O(1) c

[HACKERS] Fast AT ADD COLUMN with DEFAULTs

ple descriptor (e.g in attrdef) * When one of the getAttr or copytuple related routines is invoked the exist default is filled in instead of simply NULL padding if the tuple is shorter the requested attribute number. Is there an interest in principle in the community for this functionality? Cheers Se

Re: [HACKERS] autonomous transactions

trigger. This usage property can be used to narrow the scope of variable passing to function parameters. Cheers Serge Rielau salesforce.com -- 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] autonomous transactions

> On Aug 31, 2016, at 6:46 AM, Greg Stark wrote: > > Using a background worker mean that the autonomous transaction can't > access any state from the process memory. Parameters in plpgsql are a > symptom of this but I suspect there will be others. What happens if a > statement

Re: [HACKERS] [GENERAL] C++ port of Postgres

> On Aug 16, 2016, at 10:16 PM, Craig Ringer wrote: > > On 17 August 2016 at 09:49, Andres Freund > wrote: > > > You need to include the files surrounded by extern "C" { }. > > I'd really like to adopt the convention

Re: [HACKERS] NewYork Bombing: SQL server bomb proof!!

This is probably the worst post I have seen in a newsgroup ever. Using this tragedy so promote a product is disgusting. You are not doing the product you are promoting a favor with this. I will not comment on the technical content of this post. Serge ---(end of