Re: delta relations in AFTER triggers

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Amit Khandekar <amit(dot)khandekar(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: delta relations in AFTER triggers
Date: 2016-11-21 19:00:40
Message-ID: CAEepm=0b91nAYs=28ndY2dO0A+9JW4RmnVa=-r2-SvTFgszdrQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 22, 2016 at 7:29 AM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> On Mon, Nov 21, 2016 at 11:29 AM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> 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
>>>
>>> The intent being to emphasize that there is not one public
>>> "registry" of such objects, but context-specific collections where
>>> references are tucked away when they become available for later use
>>> in the only the appropriate context.
>
>> How about "stash"? According to my reading of Merriam-Webster's
>> definition, "stash" mostly appears to be the thing that is stored
>> (hidden), rather than the place it's stored in, but one of the
>> definitions is "hiding place", and "cache" is listed as a synonym.
>
> "Stash" seems better that "cache" or "registry", especially since
> many programmers these days seem to associate "cache" with
> pass-through proxy techniques. I first became familiar with the
> term "cache" while reading Jack London, and tend to retain some
> association with the more general definition. Clearly I am in the
> minority on that here.

I was suggesting something like QueryEnvironment because it focuses on
its role, not that fact that there are things stored in it. It's
conceptually like the environment in an interpreter, which is some
kind of namespace into which objects are bound by name. My suggestion
"SpiRelation" now seems a bit short sighted in light of your comments,
so I retract that bit. 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
expose to SQL? We would possibly have more than one list because SQL
is not "Lisp-1" in nature: relations and functions and other kinds of
object exist in different namespaces, though there may need to be
polymorphism among kinds of named relations in the same list, so
perhaps NamedTuplestore should be a node with a tag.

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-11-21 19:01:15 Re: dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.
Previous Message Robert Haas 2016-11-21 18:43:17 Re: Patch: Implement failover on libpq connect level.