Re: delta relations in AFTER triggers - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: delta relations in AFTER triggers
Date
Msg-id CAEepm=0b91nAYs=28ndY2dO0A+9JW4RmnVa=-r2-SvTFgszdrQ@mail.gmail.com
Whole thread Raw
In response to Re: delta relations in AFTER triggers  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: [HACKERS] delta relations in AFTER triggers  (Craig Ringer <craig.ringer@2ndquadrant.com>)
List pgsql-hackers
On Tue, Nov 22, 2016 at 7:29 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
> On Mon, Nov 21, 2016 at 11:29 AM, Alvaro Herrera
> <alvherre@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Patch: Implement failover on libpq connect level.
Next
From: Robert Haas
Date:
Subject: Re: dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.