Re: [HACKERS] delta relations in AFTER triggers

On Thu, May 4, 2017 at 4:23 PM, Thomas Munro wrote: > We can't possibly support transition tables on TRUNCATE (the whole > point of TRUNCATE is not to inspect all the rows so we can't collect > them), and we already reject ROW triggers on TRUNCATE, so we should >

Re: [HACKERS] delta relations in AFTER triggers

On Thu, May 4, 2017 at 5:51 AM, Thomas Munro wrote: > Reproduced here. The stack looks like this: > > frame #3: 0x00010f06f8b0 > postgres`ExceptionalCondition(conditionName="!(readptr->eflags & > 0x0002)", errorType="FailedAssertion",

Re: [HACKERS] delta relations in AFTER triggers

On Sat, May 06, 2017 at 05:34:46AM +, Noah Misch wrote: > On Fri, May 05, 2017 at 08:23:33AM +1200, Thomas Munro wrote: > > On Fri, May 5, 2017 at 12:39 AM, Neha Sharma > > wrote: > > > While testing the feature we encountered one more crash,below is the > > >

Re: [HACKERS] delta relations in AFTER triggers

On Sat, May 06, 2017 at 05:33:24AM +, Noah Misch wrote: > On Thu, May 04, 2017 at 09:51:03PM +1200, Thomas Munro wrote: > > On Thu, May 4, 2017 at 9:12 PM, Prabhat Sahu > > wrote: > > > I have been testing this for a while and observed a server crash while > >

Re: [HACKERS] delta relations in AFTER triggers

On Fri, May 05, 2017 at 08:23:33AM +1200, Thomas Munro wrote: > On Fri, May 5, 2017 at 12:39 AM, Neha Sharma > wrote: > > While testing the feature we encountered one more crash,below is the > > scenario to reproduce. > > > > create table t1 ( a int); > > create

Re: [HACKERS] delta relations in AFTER triggers

On Thu, May 04, 2017 at 09:51:03PM +1200, Thomas Munro wrote: > On Thu, May 4, 2017 at 9:12 PM, Prabhat Sahu > wrote: > > I have been testing this for a while and observed a server crash while > > referencing table column value in a trigger procedure for AFTER

Re: [HACKERS] delta relations in AFTER triggers

On Fri, May 5, 2017 at 12:39 AM, Neha Sharma wrote: > While testing the feature we encountered one more crash,below is the > scenario to reproduce. > > create table t1 ( a int); > create table t2 ( a int); > insert into t1 values (11),(12),(13); > > create or replace

Re: [HACKERS] delta relations in AFTER triggers

On Thu, May 4, 2017 at 9:12 PM, Prabhat Sahu wrote: > I have been testing this for a while and observed a server crash while > referencing table column value in a trigger procedure for AFTER DELETE > trigger. > > -- Steps to reproduce: > CREATE TABLE t1(c1 int); >

Re: [HACKERS] delta relations in AFTER triggers

> > Great. Thanks. I wonder if there is some way we can automatically > include code fragments in the documentation without keeping them in > sync manually. > > In whatever extra docs you add, could you include an example of an INSERT ON CONFLICT, and potentially a CTE query that does two

Re: [HACKERS] delta relations in AFTER triggers

On Wed, Apr 5, 2017 at 11:49 AM, Kevin Grittner wrote: > Worked on the docs some more and then pushed it. > > Nice job cutting the number of *.[ch] lines by 30 while adding support for > the other three core PLs. :-) Great. Thanks. I wonder if there is some way we can

Re: [HACKERS] delta relations in AFTER triggers

On Mon, Apr 3, 2017 at 7:16 PM, Thomas Munro wrote: > On Tue, Apr 4, 2017 at 3:41 AM, Kevin Grittner wrote: >> On Mon, Apr 3, 2017 at 8:59 AM, Tom Lane wrote: >>> Thomas Munro writes: Or

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Apr 4, 2017 at 3:41 AM, Kevin Grittner wrote: > On Mon, Apr 3, 2017 at 8:59 AM, Tom Lane wrote: >> Thomas Munro writes: >>> Or perhaps the code to inject trigger data transition tables into SPI >>> (a near identical

Re: [HACKERS] delta relations in AFTER triggers

On Mon, Apr 3, 2017 at 8:59 AM, Tom Lane wrote: > Thomas Munro writes: >> Or perhaps the code to inject trigger data transition tables into SPI >> (a near identical code block these three patches) should be somewhere >> common so that each PLs

Re: [HACKERS] delta relations in AFTER triggers

Thomas Munro writes: > Or perhaps the code to inject trigger data transition tables into SPI > (a near identical code block these three patches) should be somewhere > common so that each PLs would only need to call a function. If so, > where should that go? spi.c?

Re: [HACKERS] delta relations in AFTER triggers

On Mon, Apr 3, 2017 at 3:50 PM, Thomas Munro wrote: > Please also find attached a rebased patch to add pl/python support, > and new equivalent patches for pl/perl and pl/tcl. I am planning to > add these to PG11 CF1, unless you think we should be more aggressive >

Re: [HACKERS] delta relations in AFTER triggers

Happy to see this committed! And thanks for the co-author credit, which is a generous exaggeration. I was still a bit confused about this and poked at it a bit: On Wed, Mar 8, 2017 at 1:28 PM, Kevin Grittner wrote: >> /* >> + * Capture the NEW and OLD transition TABLE

Re: [HACKERS] delta relations in AFTER triggers

> > > That, and I suspect that people will start using this infrastructure > > for some very cool projects. > > Yeah, I was excited to see this committed. It practically begs to be > used for plpgsql TABLE valued variables backed by tuplestores. > (also very excited about this!)

Re: [HACKERS] delta relations in AFTER triggers

On 1 April 2017 at 02:29, David Fetter wrote: > On Fri, Mar 31, 2017 at 12:20:51PM -0500, Kevin Grittner wrote: >> On Thu, Mar 30, 2017 at 11:51 AM, Kevin Grittner wrote: >> >> > New version attached. It needs some of these problem cases added >> > to the

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Mar 31, 2017 at 12:20:51PM -0500, Kevin Grittner wrote: > On Thu, Mar 30, 2017 at 11:51 AM, Kevin Grittner wrote: > > > New version attached. It needs some of these problem cases added > > to the testing, and a mention in the docs that only C and plpgsql > > triggers

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Mar 31, 2017 at 12:58 PM, Robert Haas wrote: > On Fri, Mar 31, 2017 at 1:50 PM, Tom Lane wrote: >> I would vote for calling the struct typedef EphemeralNamedRelation and >> using the abbreviation ENR (capitalized that way, not as Enr) in

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Mar 31, 2017 at 1:50 PM, Tom Lane wrote: > Kevin Grittner writes: >> On Thu, Mar 23, 2017 at 7:14 PM, Thomas Munro >> wrote: >>> my only other comment would be a bikeshed issue: >>> Enr isn't a great name for a

Re: [HACKERS] delta relations in AFTER triggers

Kevin Grittner writes: > On Thu, Mar 23, 2017 at 7:14 PM, Thomas Munro > wrote: >> my only other comment would be a bikeshed issue: >> Enr isn't a great name for a struct. > I know, but EphemeralNamedRelation starts to get kinda long, >

Re: [HACKERS] delta relations in AFTER triggers

On Thu, Mar 30, 2017 at 11:51 AM, Kevin Grittner wrote: > New version attached. It needs some of these problem cases added to > the testing, and a mention in the docs that only C and plpgsql > triggers can use the feature so far. I'll add those tomorrow. Done and attached.

Re: [HACKERS] delta relations in AFTER triggers

On Thu, Mar 23, 2017 at 7:14 PM, Thomas Munro wrote: > my only other comment would be a bikeshed issue: > Enr isn't a great name for a struct. I know, but EphemeralNamedRelation starts to get kinda long, especially when making the normal sorts of concatenations.

Re: [HACKERS] delta relations in AFTER triggers

On Thu, Mar 23, 2017 at 11:36 PM, Thomas Munro wrote: > One more thought: should this be allowed? > > postgres=# create table mytab (i int) partition by list (i); > CREATE TABLE > postgres=# create table mytab1 partition of mytab for values in (42); > CREATE TABLE

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Mar 24, 2017 at 1:14 PM, Thomas Munro wrote: > On Tue, Mar 14, 2017 at 7:51 AM, Kevin Grittner wrote: >> On Sun, Mar 12, 2017 at 4:08 PM, Thomas Munro >> wrote: >>> I found a new way to break it: run the

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Mar 24, 2017 at 5:36 PM, Thomas Munro wrote: > On Fri, Mar 24, 2017 at 1:14 PM, Thomas Munro > wrote: >> If that's fixed and the permissions question can be waved away by >> saying it's the same as the per-row situation, my

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Mar 24, 2017 at 1:14 PM, Thomas Munro wrote: > If that's fixed and the permissions question can be waved away by > saying it's the same as the per-row situation, my only other comment > would be a bikeshed issue: Enr isn't a great name for a struct. One

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Mar 14, 2017 at 7:51 AM, Kevin Grittner wrote: > On Sun, Mar 12, 2017 at 4:08 PM, Thomas Munro > wrote: >> I found a new way to break it: run the trigger function so >> that the plan is cached by plpgsql, then ALTER TABLE incompatibly, >>

Re: [HACKERS] delta relations in AFTER triggers

Kevin Grittner wrote: > >> What is necessary to indicate an additional SQL feature covered? > > > > I assume you're talking about information_schema.sql_features > > I had forgotten we had that in a table. I was thinking more of the docs: > >

Re: [HACKERS] delta relations in AFTER triggers

On Sun, Mar 12, 2017 at 4:08 PM, Thomas Munro wrote: > I found a new way to break it: run the trigger function so > that the plan is cached by plpgsql, then ALTER TABLE incompatibly, > then run the trigger function again. See attached. The first part doesn't seem

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Mar 10, 2017 at 11:48 AM, Kevin Grittner wrote: > On Tue, Mar 7, 2017 at 6:28 PM, Kevin Grittner wrote: > >> New patch attached. > > And bit-rotted less than 24 hours later by fcec6caa. > > New patch attached just to fix bit-rot. > > That conflicting

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Mar 7, 2017 at 6:28 PM, Kevin Grittner wrote: > New patch attached. And bit-rotted less than 24 hours later by fcec6caa. New patch attached just to fix bit-rot. That conflicting patch might be a candidate to merge into the new Ephemeral Named Relation provided by my

Re: [HACKERS] delta relations in AFTER triggers

On Mon, Feb 20, 2017 at 7:44 PM, Thomas Munro wrote: > Was it intentional that this test doesn't include any statements that > reach the case where the trigger does RAISE EXCEPTION 'RI error'? > From the output generated there doesn't seem to be any evidence that >

Re: [HACKERS] delta relations in AFTER triggers

On Thu, Mar 2, 2017 at 9:04 AM, David Steele wrote: > On 2/20/17 10:43 PM, Thomas Munro wrote: >> Based on a suggestion from Robert off-list I tried inserting into a >> delta relation from a trigger function and discovered that it >> segfaults: >> >> * frame #0:

Re: [HACKERS] delta relations in AFTER triggers

Hi Kevin, On 2/20/17 10:43 PM, Thomas Munro wrote: > On Tue, Feb 21, 2017 at 7:14 AM, Thomas Munro > wrote: >> On Fri, Jan 20, 2017 at 2:49 AM, Kevin Grittner wrote: >>> Attached is v9 which fixes bitrot from v8. No other changes. >>> >>> Still

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Feb 21, 2017 at 7:14 AM, Thomas Munro wrote: > On Fri, Jan 20, 2017 at 2:49 AM, Kevin Grittner wrote: >> Attached is v9 which fixes bitrot from v8. No other changes. >> >> Still needs review. Based on a suggestion from Robert off-list I

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Jan 20, 2017 at 2:49 AM, Kevin Grittner wrote: > Attached is v9 which fixes bitrot from v8. No other changes. > > Still needs review. This patch still applies, builds cleanly after a small modification, includes regression tests and the tests past. The modification I

Re: [HACKERS] delta relations in AFTER triggers

On Sat, Jan 21, 2017 at 6:37 AM, Kevin Grittner wrote: > On Fri, Jan 20, 2017 at 2:08 PM, Nico Williams wrote: >> On Fri, Jan 20, 2017 at 01:37:33PM -0600, Kevin Grittner wrote: > >>> There is currently plenty of room for pseudo-MV implementations, >>>

Re: Updating MATERIALIZED VIEWs (Re: [HACKERS] delta relations in AFTER triggers)

On 1/20/17 5:38 PM, Nico Williams wrote: If these triggers could be automatically generated, that sure would be nice, but some control would be needed over when to update the MV vs. mark it as needing a refresh. FWIW, pg_classy[1], which is still a work in progress, would allow for that. The

Updating MATERIALIZED VIEWs (Re: [HACKERS] delta relations in AFTER triggers)

[Looking at your patch I see that it's not quite related to MVs, so I'm changing the Subject. Apologies for the noise.] [Responding out of order.] On Fri, Jan 20, 2017 at 03:37:20PM -0600, Kevin Grittner wrote: > On Fri, Jan 20, 2017 at 2:08 PM, Nico Williams wrote: > >

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Jan 20, 2017 at 2:08 PM, Nico Williams wrote: > On Fri, Jan 20, 2017 at 01:37:33PM -0600, Kevin Grittner wrote: >> There is currently plenty of room for pseudo-MV implementations, >> and may be for a while. It's a good indication of the need for the >> feature in

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Jan 20, 2017 at 01:37:33PM -0600, Kevin Grittner wrote: > On Thu, Jan 19, 2017 at 4:14 PM, Nico Williams wrote: > > Reviews welcome! I will review. > There is currently plenty of room for pseudo-MV implementations, > and may be for a while. It's a good

Re: [HACKERS] delta relations in AFTER triggers

On Thu, Jan 19, 2017 at 4:14 PM, Nico Williams wrote: > I hope what I've done about delta relations will be mostly irrelevant > given your patch (which I've not looked at in detail), Reviews welcome! > but just FYI, > I've built an alternate, all-SQL-coded materialized

Re: [HACKERS] delta relations in AFTER triggers

Attached is v10 which fixes bitrot from v9 caused by ea15e186. Still needs review. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company transition-v10.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list

Re: [HACKERS] delta relations in AFTER triggers

On Sat, Dec 17, 2016 at 08:15:49PM -0600, Kevin Grittner wrote: > On Sun, Dec 4, 2016 at 11:35 PM, Haribabu Kommi > wrote: > > Moved to next CF with "waiting on author" status. > > [...] I hope what I've done about delta relations will be mostly irrelevant given your

Re: [HACKERS] delta relations in AFTER triggers

Attached is v9 which fixes bitrot from v8. No other changes. Still needs review. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company transition-v9.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list

Re: [HACKERS] delta relations in AFTER triggers

On Sun, Dec 18, 2016 at 3:15 PM, Kevin Grittner wrote: > Patch v8 ... FWIW here's that plpython patch, adjusted to apply on top of your latest patch. -- Thomas Munro http://www.enterprisedb.com delta-relations-plpython.patch Description: Binary data -- Sent via

Re: [HACKERS] delta relations in AFTER triggers

On Sun, Dec 18, 2016 at 3:15 PM, Kevin Grittner wrote: > On Sun, Dec 4, 2016 at 11:35 PM, Haribabu Kommi > wrote: > >> Moved to next CF with "waiting on author" status. > > Patch v8 attempts to address the issues explicitly raised in > Thomas Munro's

Re: [HACKERS] delta relations in AFTER triggers

On 22 Nov. 2016 03:01, "Thomas Munro" wrote: How about a QueryEnvironment (as shown in the patch I posted) that contains a list of NamedTuplestore pointers (the SpiRelation struct in the patch I posted, renamed) and in future perhaps lists of other

Re: [HACKERS] delta relations in AFTER triggers

On 22 Nov. 2016 01:05, "Kevin Grittner" wrote: Right, I think we should assume that there will be other ways people want to use parts of what is done here, including building tuplestores through other means and referencing them in queries. Yes. PL/pgsql table-valued

Re: [HACKERS] delta relations in AFTER triggers

On Sun, Dec 4, 2016 at 11:35 PM, Haribabu Kommi wrote: > Moved to next CF with "waiting on author" status. Patch v8 attempts to address the issues explicitly raised in Thomas Munro's review. An opaque query environment is created that, for now, only passes through

Re: [HACKERS] delta relations in AFTER triggers

On Wed, Nov 23, 2016 at 10:02 AM, Jim Nasby wrote: > On 11/21/16 3:49 AM, Craig Ringer wrote: > >> After going through that experience, I now agree with Kevin: an >>> > interface where a new SPI interface lets PLs push a named tuplestore >>> > into the SPI connection to

Re: [HACKERS] delta relations in AFTER triggers

On 11/21/16 3:49 AM, Craig Ringer wrote: After going through that experience, I now agree with Kevin: an > interface where a new SPI interface lets PLs push a named tuplestore > into the SPI connection to make it available to SQL seems like the > simplest and tidiest way. That also offers a

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Nov 22, 2016 at 7:29 AM, Kevin Grittner wrote: > On Mon, Nov 21, 2016 at 11:29 AM, Alvaro Herrera > wrote: > >>> When I used the word "cache" here, I was thinking more of this >>> English language definition: >>> >>> a : a hiding place

Re: [HACKERS] delta relations in AFTER triggers

On Mon, Nov 21, 2016 at 11:29 AM, Alvaro Herrera wrote: >> When I used the word "cache" here, I was thinking more of this >> English language definition: >> >> a : a hiding place especially for concealing and preserving >>provisions or implements >> b : a

Re: [HACKERS] delta relations in AFTER triggers

Kevin Grittner wrote: > On Mon, Nov 21, 2016 at 1:05 AM, Thomas Munro > wrote: > > Also, Tsrcache is strangely named: it's not exactly a cache, it's > > more of a registry. > > When I used the word "cache" here, I was thinking more of this > English language

Re: [HACKERS] delta relations in AFTER triggers

On Mon, Nov 21, 2016 at 12:04 PM, Kevin Grittner wrote: >> Also, Tsrcache is strangely named: it's not exactly a cache, it's >> more of a registry. > > When I used the word "cache" here, I was thinking more of this > English language definition: > > a : a hiding place

Re: [HACKERS] delta relations in AFTER triggers

Thanks for the review! Will respond further after reviewing your suggested patches; this is a quick response just to the contents of the email. On Mon, Nov 21, 2016 at 1:05 AM, Thomas Munro wrote: > Both ways have attracted criticism: the first involves touching

Re: [HACKERS] delta relations in AFTER triggers

On 21 November 2016 at 15:05, Thomas Munro wrote: > After going through that experience, I now agree with Kevin: an > interface where a new SPI interface lets PLs push a named tuplestore > into the SPI connection to make it available to SQL seems like the >

Re: [HACKERS] delta relations in AFTER triggers

On Sun, Oct 30, 2016 at 10:35 AM, Kevin Grittner wrote: > On Sun, Oct 2, 2016 at 11:20 PM, Michael Paquier > wrote: >> Not as big as I thought, only 2k when both patches are combined... The >> patch without noapi in its name needs to be applied

Re: [HACKERS] delta relations in AFTER triggers

On Wed, Nov 2, 2016 at 4:09 PM, Adam Brusselback wrote: >> There may be some situations where crawling the indexes a row at a >> time will perform better than this by enough to want to retain that >> option. > > If an index existed, wouldn't it still be able to use that

Re: [HACKERS] delta relations in AFTER triggers

> > There may be some situations where crawling the indexes a row at a > time will perform better than this by enough to want to retain that > option. If an index existed, wouldn't it still be able to use that in the set-based implementation? Is there something which would make doing the check

Re: [HACKERS] delta relations in AFTER triggers

> 2016-11-02 15:57 GMT+01:00 Kevin Grittner : >> On Sun, Oct 30, 2016 at 10:35 AM, Kevin Grittner wrote: >> >>> SPI support would also >>> allow us to consider using set logic for validating foreign keys, >>> instead of the one-row-at-a-time approach

Re: [HACKERS] delta relations in AFTER triggers

> > The delete of about one million rows from a "parent" table with no > matching rows in the "child" table, and no index on referencing > column in the child table, took 24:17.969 using current triggers > and 00:03.262 using the set-based triggers. Yes, that reduces > current run time for that

Re: [HACKERS] delta relations in AFTER triggers

2016-11-02 15:57 GMT+01:00 Kevin Grittner : > On Sun, Oct 30, 2016 at 10:35 AM, Kevin Grittner > wrote: > > > SPI support would also > > allow us to consider using set logic for validating foreign keys, > > instead of the one-row-at-a-time approach currently

Re: [HACKERS] delta relations in AFTER triggers

Attached is a minor fix to go on top of transition-tsr for issues found yesterday in testing. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c index 53bfd4b..2da841e

Re: [HACKERS] delta relations in AFTER triggers

On Sun, Oct 30, 2016 at 10:35 AM, Kevin Grittner wrote: > SPI support would also > allow us to consider using set logic for validating foreign keys, > instead of the one-row-at-a-time approach currently used. Just as a proof of concept for this I used the attached test case

Re: [HACKERS] delta relations in AFTER triggers

On Sun, Oct 2, 2016 at 11:20 PM, Michael Paquier wrote: > On Sat, Sep 10, 2016 at 7:28 AM, Kevin Grittner wrote: >> v6 fixes recently-introduced bit-rot. > > Not as big as I thought, only 2k when both patches are combined... The > patch without noapi

Re: [HACKERS] delta relations in AFTER triggers

On Sat, Sep 10, 2016 at 7:28 AM, Kevin Grittner wrote: > v6 fixes recently-introduced bit-rot. Not as big as I thought, only 2k when both patches are combined... The patch without noapi in its name needs to be applied first, and after the patch with noapi can be applied. 60

Re: [HACKERS] delta relations in AFTER triggers

v6 fixes recently-introduced bit-rot. Kevin Grittner On Wed, Aug 31, 2016 at 3:24 PM, Kevin Grittner wrote: > I have merged in the changes since v4 (a year and a half ago) and > cured all bit-rot I found, to get the attached v5 which runs `make > check world` without problem

Re: [HACKERS] delta relations in AFTER triggers

I have merged in the changes since v4 (a year and a half ago) and cured all bit-rot I found, to get the attached v5 which runs `make check world` without problem -- including the tests added for this feature. I did remove the contrib code that David Fetter wrote to demonstrate the correctness and

Re: [HACKERS] delta relations in AFTER triggers

On Fri, May 13, 2016 at 2:37 PM, Kevin Grittner wrote: > On Fri, May 13, 2016 at 1:02 PM, David Fetter wrote: >> On Thu, Jan 22, 2015 at 02:41:42PM +, Kevin Grittner wrote: > >>> [ideas on how to pass around references to ephemeral relations] >> >>

Re: [HACKERS] delta relations in AFTER triggers

On Fri, May 13, 2016 at 1:02 PM, David Fetter wrote: > On Thu, Jan 22, 2015 at 02:41:42PM +, Kevin Grittner wrote: >> [ideas on how to pass around references to ephemeral relations] > > [almost 17 months later] > > It seems like now is getting close to the time to get this

Re: [HACKERS] delta relations in AFTER triggers

On Thu, Jan 22, 2015 at 02:41:42PM +, Kevin Grittner wrote: > Robert Haas wrote: > > > Another idea is to change what actually gets passed to the parser > > callback. Right now we just pass the PLpgSQL_expr. If we created a > > new structure that contained that plus

Re: [HACKERS] delta relations in AFTER triggers

On Thu, Oct 23, 2014 at 11:19 AM, Robert Haas robertmh...@gmail.com wrote: So what I'm imagining now is: 1. During parse analysis, p_tableref_hook gets control and calls addRangeTableEntryForTuplestore(), creating an RTE of type RTE_TUPLESTORE. The RTE stores an integer parameter-index. 2.

Re: [HACKERS] delta relations in AFTER triggers

Robert Haas robertmh...@gmail.com wrote: Another idea is to change what actually gets passed to the parser callback. Right now we just pass the PLpgSQL_expr. If we created a new structure that contained that plus the PLpgSQL_execstate, we'd be in fine shape. But this sort of gets at the

Re: [HACKERS] delta relations in AFTER triggers

On Wed, Oct 22, 2014 at 5:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: I was thinking that the hook would return a RelationParam. When parse analysis sees the returned RelationParam, it adds an entry for that to the range table, and creates the RangeTblRef for it. The way you describe it works

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Sep 23, 2014 at 1:51 PM, Tom Lane t...@sss.pgh.pa.us wrote: Add a new p_tableref_hook function pointer, similar to p_paramref_hook. Whenever the parser sees a RangeVar that it doesn't recognize (or actually, I think it should call it *before* resolving regular tables, but let's ignore

Re: [HACKERS] delta relations in AFTER triggers

On 10/22/2014 11:10 PM, Robert Haas wrote: On Tue, Sep 23, 2014 at 1:51 PM, Tom Lane t...@sss.pgh.pa.us wrote: Add a new p_tableref_hook function pointer, similar to p_paramref_hook. Whenever the parser sees a RangeVar that it doesn't recognize (or actually, I think it should call it *before*

Re: [HACKERS] delta relations in AFTER triggers

Heikki Linnakangas hlinnakan...@vmware.com writes: On 10/22/2014 11:10 PM, Robert Haas wrote: Studying this proposed design a bit further, I am a little fuzzy on what is supposed to happen in this design during parse analysis. In Kevin's current code, after checking whether a RangeVar might

Re: [HACKERS] delta relations in AFTER triggers

On 09/25/2014 06:54 PM, Kevin Grittner wrote: Heikki Linnakangas hlinnakan...@vmware.com wrote: You cast the TuplestoreRelation to Plan, and pass it to CopyPlanFields. That will crash, because TuplestoreRelation is nothing like a Plan: Oops. That's a copy/paste error I should have noticed.

Re: [HACKERS] delta relations in AFTER triggers

Heikki Linnakangas hlinnakan...@vmware.com wrote: You cast the TuplestoreRelation to Plan, and pass it to CopyPlanFields. That will crash, because TuplestoreRelation is nothing like a Plan: Oops. That's a copy/paste error I should have noticed. Fixed, even though the node type might be going

Re: [HACKERS] delta relations in AFTER triggers

On 09/25/2014 11:54 PM, Kevin Grittner wrote: I have fixed the bug reported by Heikki; be sure to grab that. Will do. I have been merging in changes to master as I go, so that bit rot doesn't accumulate, but I don't squash or rebase; hopefully that style works for you. IMO it only really

Re: [HACKERS] delta relations in AFTER triggers

On 09/24/2014 12:22 AM, Kevin Grittner wrote: Heikki Linnakangas hlinnakan...@vmware.com wrote: instead of passing parameters to the SPI calls individually, you invented SPI_register_tuplestore which affects all subsequent SPI calls. All subsequent SPI calls on that particular SPI connection

Re: [HACKERS] delta relations in AFTER triggers

On 08/28/2014 05:03 AM, Kevin Grittner wrote: I don't have to squint that hard -- I've always been comfortable with the definition of a table as a relation variable, and it's not too big a stretch to expand that to a tuplestore. ;-) In fact, I will be surprised if someone doesn't latch onto

Re: [HACKERS] delta relations in AFTER triggers

On 09/15/2014 10:25 PM, Kevin Grittner wrote: I broke out the changes from the previous patch in multiple commits in my repository on github: *Thankyou* That gives me the incentive to pull it and test it. A nice patch series published in a git repo is so much easier to work with than a giant

Re: [HACKERS] delta relations in AFTER triggers

On 09/15/2014 05:25 PM, Kevin Grittner wrote: Tom Lane t...@sss.pgh.pa.us wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: On 08/30/2014 12:15 AM, Kevin Grittner wrote: If we were to go with the hooks as you propose, we would still need to take the information from TriggerData and

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Sep 23, 2014 at 12:46 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 09/15/2014 05:25 PM, Kevin Grittner wrote: Now, how do we make the tuplestores work similarly? Here's what I think we should do: Add a new p_tableref_hook function pointer, similar to p_paramref_hook.

Re: [HACKERS] delta relations in AFTER triggers

Robert Haas robertmh...@gmail.com writes: On Tue, Sep 23, 2014 at 12:46 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: Now, how do we make the tuplestores work similarly? Here's what I think we should do: Add a new p_tableref_hook function pointer, similar to p_paramref_hook.

Re: [HACKERS] delta relations in AFTER triggers

On 09/23/2014 08:51 PM, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Sep 23, 2014 at 12:46 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: Now, how do we make the tuplestores work similarly? Here's what I think we should do: Add a new p_tableref_hook function

Re: [HACKERS] delta relations in AFTER triggers

Thanks for reviewing this. I will spend some time looking at your recommendations in detail and seeing what it would take to implement them, and whether I agree that is better; but I wanted to point out a couple things regarding the SPI interface where I'm not sure you realize what's currently

Re: [HACKERS] delta relations in AFTER triggers

Tom Lane t...@sss.pgh.pa.us wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: On 08/30/2014 12:15 AM, Kevin Grittner wrote: If we were to go with the hooks as you propose, we would still need to take the information from TriggerData and put it somewhere else for the hook to

Re: [HACKERS] delta relations in AFTER triggers

Marti Raudsepp ma...@juffo.org wrote: On Mon, Sep 1, 2014 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote: The concept of lightweight relations that pop into existence when a certain kind of trigger definition is used somewhere in the function stack, without a CREATE TABLE, without being

Re: [HACKERS] delta relations in AFTER triggers

Kevin Grittner kgri...@ymail.com wrote: Marti Raudsepp ma...@juffo.org wrote: What are the interactions with search_path? Pretty much the same as the interactions of RTEs with search_path. If the apparent relation name is not schema-qualified, parse analysis first tries to resolve the

Re: [HACKERS] delta relations in AFTER triggers

On Wed, Sep 3, 2014 at 10:49 PM, Kevin Grittner kgri...@ymail.com wrote: Marti Raudsepp ma...@juffo.org wrote: The concept of lightweight relations that pop into existence when a certain kind of trigger definition is used somewhere in the function stack, without a CREATE TABLE, without being

Re: [HACKERS] delta relations in AFTER triggers

Marti Raudsepp ma...@juffo.org wrote: On Wed, Sep 3, 2014 at 10:49 PM, Kevin Grittner kgri...@ymail.com wrote: Marti Raudsepp ma...@juffo.org wrote: The concept of lightweight relations that pop into existence when a certain kind of trigger definition is used somewhere in the function stack,

Re: [HACKERS] delta relations in AFTER triggers

On Mon, Sep 1, 2014 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote: OTOH, I agree with Kevin that the things we're talking about are lightweight relations not variables. My worry is that PL/pgSQL and Postgres's SQL dialect is turning into a Frankenstein monster with many ways to do the same

Re: [HACKERS] delta relations in AFTER triggers

On 08/30/2014 12:15 AM, Kevin Grittner wrote: Heikki Linnakangas hlinnakan...@vmware.com wrote: On 08/28/2014 12:03 AM, Kevin Grittner wrote: Heikki Linnakangas hlinnakan...@vmware.com wrote: I suggest adding a new hook to the ParseState struct, (p_rangevar_hook ?). The planner calls it

Re: [HACKERS] delta relations in AFTER triggers

Heikki Linnakangas hlinnakan...@vmware.com writes: On 08/30/2014 12:15 AM, Kevin Grittner wrote: If we were to go with the hooks as you propose, we would still need to take the information from TriggerData and put it somewhere else for the hook to reference. Sure. FWIW, I agree with Heikki

  1   2   >