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 sessio

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 outlive

Re: [HACKERS] MERGE SQL Statement for PG11

via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx&cv=9.8.79&pv=10.12.6&source=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 I have > never seen

Re: [HACKERS] generated columns

rated_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 co

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 in v10 and pull that part >

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 wil

Re: [HACKERS] CTE inlining

ent 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 prove semantic equivalence. Cheers S

Re: [HACKERS] Cached plans and statement generalization

via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx&cv=9.4.52&pv=10.11.6&source=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; CREATE SCHEMA b

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 > > SELECT $1::CHAR(10) ||

Re: [HACKERS] Cached plans and statement generalization

On Tue, Apr 25, 2017 at 9:45 AM, Konstantin Knizhnik 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 integer literals in context

Re: [HACKERS] Cached plans and statement generalization

ning 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 <http://salesforce.com/>

Re: [HACKERS] Fast Default WIP patch for discussion

6&source=email_footer_2] On Wed, Apr 5, 2017 at 4:47 PM, Andres Freund 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 > imp

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 MODU

Re: [HACKERS] Packages: Again

On Fri, Jan 13, 2017 at 4:24 PM, Peter Geoghegan wrote: On Fri, Jan 13, 2017 at 3:44 PM, Serge Rielau wrote: > And sometimes the community DOES go its own way rather than implementing the > standard. For example by rejecting the MERGE statement in favor of another > syntax and

Re: [HACKERS] Packages: Again

On Fri, Jan 13, 2017 at 2:46 PM, Kevin Grittner wrote: On Fri, Jan 13, 2017 at 12:35 PM, Serge Rielau wrote: > Yes my proposal to nest schemata is “radical” and this community > is not falling into that camp. > But there is nothing holy about database.schema.object.attribute It is ma

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 getting clearance for that fro

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 some benefits of sharing >

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 database.schema.object Yes my proposal to nes

Re: [HACKERS] Packages: Again

pily lobby 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 a

Re: [HACKERS] Fast Default WIP patch for discussion

> On Oct 28, 2016, at 5:46 AM, Robert Haas wrote: > > On Fri, Oct 21, 2016 at 7:15 PM, Serge Rielau 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 bi

Re: [HACKERS] Fast Default WIP patch for discussion

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 wrote: > > On 26-10-2016 12:43, Serge Rielau wrote: >> Posting to this group on a Friday evening was obviousl

Re: [HACKERS] Fast Default WIP patch for discussion

:15 PM, Serge Rielau 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. >It would be feasible to

[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 instea

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 [http://www.ibm.com/support/k

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 > a separate object from the column for purpos

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 code where general exp

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

> On Oct 6, 2016, at 5:25 AM, Vitaly Burovoy wrote: > > On 10/6/16, Simon Riggs wrote: >> On 6 October 2016 at 04:43, Serge Rielau wrote: >>>>> Or should I compose some sort of a design document? >> >> Having read this thread, I'm a little u

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

> On Oct 5, 2016, at 5:52 PM, Vitaly Burovoy wrote: > > On 10/5/16, Serge Rielau wrote: >> I want to point out as a minor "extension" that there is no need for the >> default to be immutable. It is merely required that the default is evaluate >> at time o

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

efault 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

e. 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 wrote: On 10/5/16, Andres Freund 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 columns to a table >> without a table rewrite (i.e. a

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

On Wed, Oct 5, 2016 at 2:45 PM, Vitaly Burovoy wrote: On 10/5/16, Serge Rielau 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) cost) from the > nullable-without-default to a more ge

[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

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 timeout occurs dur

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 used by many libraries etc of doing > this aut

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 broadca