Re: delta relations in AFTER triggers

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: delta relations in AFTER triggers
Дата
Msg-id CAEepm=0b91nAYs=28ndY2dO0A+9JW4RmnVa=-r2-SvTFgszdrQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: delta relations in AFTER triggers  (Kevin Grittner <kgrittn@gmail.com>)
Ответы Re: [HACKERS] delta relations in AFTER triggers
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Patch: Implement failover on libpq connect level.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.