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
> reject transition tables on STATEM
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", fileName="tuplestore.c",
> lineNumber=1237) + 128 at a
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
> > > scenario to reproduce.
> > >
> >
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
> > > referencing table column value
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 table t2 ( a int);
> > insert into
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 DELETE
> > trigger.
> >
> > -- Step
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 function my_trig() returns tri
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);
> CREATE TABLE t2(cc1 int);
> INS
>
> 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 operati
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 automatically
include cod
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 perhaps the code to inject trigger data transition tables into SPI
(a near identical code block th
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 code block these three patches) should be somewhere
>>> common so that e
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 would only need to call a function. If so,
>> where
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?
regard
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
> given the extra time?
Or perhap
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 tuplestores (if specifie
>
> > 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!)
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 testing, and a mention in the docs that
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 can use the feature
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 related
>> function names, where that seemed sensi
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 struct.
>
>> I know, but EphemeralNamedRelation starts to get kinda long,
>>
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,
> especially when making the normal sorts of concatenations.
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.
Now the question is
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. I
started making the change and
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
> postgres=# create function my_
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 trigger function so
>>> that the plan is cached by plpgsql, then ALTER TABLE incompa
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 only other comment
>> would be a bikeshed issue: Enr isn't a grea
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 more thought: should this be allowe
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,
>> then run the trigger function again. See attached
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:
>
> https://www.postgresql.org/docs/current/static/featu
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 so bad. Using the transition t
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 patch might be a candidate to merge in
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 patch, for more fle
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
> the triggers run at all, though
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: 0x0001057705a6
>> postgres`a
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 needs review.
>
> Based on a suggestion from Robe
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 tried inserting into a
delta relation from a trigg
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
needed to make was
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,
>>> and may be for a while. It's a good indicat
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 i
[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:
> > BTW, automatic updates o
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 core. An implementation
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 indication of the need for the
>
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 view system that
> captur
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 (pgsql-hackers@postgresql
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 patch (which I've not looked
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 (pgsql-hackers@postgresql.o
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 pgsql-hackers mailing list (p
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 review. An opaque query environment is create
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 ephemeral/transient objects that we want to
ex
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 variables for one thing.
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 ephemeral named relations, of
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 make it available to SQL s
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 hand
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 especially for concealing and preserving
>>>
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 secure place of storage
>>
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 definition:
>
> a : a hiding pla
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 especially for concealing
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
> basically every core function
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
> simplest and tidiest way.
That also of
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 first, and after
>> the patch with noapi can be ap
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 in the set-based
> implemen
>
> 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
se
> 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 used.
>>
>> Just as a proof of concep
>
> 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 ca
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 used.
>
> Just as a proof of concept f
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 1006
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
to create foreign key
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 in its name needs to be applied first, and aft
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 files changed, 2073 i
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 -- including the te
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
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]
>>
>> [almost 17 months later]
>>
>> It seems like
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 into
> master. The
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 the PLpgSQL_execstate, w
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 the PLpgSQL_execstate, we'd be
> in fine shape. But this sort of gets at the root of the problem
On Thu, Oct 23, 2014 at 11:19 AM, Robert Haas 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. Path generatio
On Wed, Oct 22, 2014 at 5:29 PM, Tom Lane 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 too, but mani
Heikki Linnakangas 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 be a CTE
>> refere
On 10/22/2014 11:10 PM, Robert Haas wrote:
On Tue, Sep 23, 2014 at 1:51 PM, Tom Lane 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 ta
On Tue, Sep 23, 2014 at 1:51 PM, Tom Lane 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 that fo
On Thu, Sep 4, 2014 at 12:14 AM, Kevin Grittner wrote:
>> Did I miss something?
>
> Apparently. I did a search on the document and counted and got 101
> occurrences of "transition table".
> | A transient table is a named table that may come into existence
> | implicitly during the evaluation of a
On 09/25/2014 06:54 PM, Kevin Grittner wrote:
Heikki Linnakangas 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
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
Heikki Linnakangas 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 away. Since all of t
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
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 on
On 09/24/2014 12:22 AM, Kevin Grittner wrote:
Heikki Linnakangas 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 until it
is closed, exc
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 bei
On 09/23/2014 08:51 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Sep 23, 2014 at 12:46 PM, Heikki Linnakangas
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.
Whenever the p
Robert Haas writes:
> On Tue, Sep 23, 2014 at 12:46 PM, Heikki Linnakangas
> 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.
>> Whenever the parser sees a RangeVar tha
On Tue, Sep 23, 2014 at 12:46 PM, Heikki Linnakangas
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.
> Whenever the parser se
On 09/15/2014 05:25 PM, Kevin Grittner wrote:
Tom Lane wrote:
Heikki Linnakangas 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 refer
Tom Lane wrote:
> Heikki Linnakangas 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 agre
Marti Raudsepp wrote:
> On Wed, Sep 3, 2014 at 10:49 PM, Kevin Grittner wrote:
>> Marti Raudsepp 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 be
On Wed, Sep 3, 2014 at 10:49 PM, Kevin Grittner wrote:
> Marti Raudsepp 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 discoverable in
>> inform
Kevin Grittner wrote:
> Marti Raudsepp 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 name as an RTE, and if that
Marti Raudsepp wrote:
> On Mon, Sep 1, 2014 at 9:09 PM, Tom Lane 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 discoverable in
> information_sche
On Mon, Sep 1, 2014 at 9:09 PM, Tom Lane 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 thing, each having
di
Heikki Linnakangas 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 on this point.
1 - 100 of 146 matches
Mail list logo