Re: per-tablespace random_page_cost/seq_page_cost

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: per-tablespace random_page_cost/seq_page_cost
Дата
Msg-id 20091102174016.GC4617@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: per-tablespace random_page_cost/seq_page_cost  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: per-tablespace random_page_cost/seq_page_cost
Список pgsql-hackers
Robert Haas escribió:

> I don't see anything in this code that is very rel-specific, so I
> think it would be possible to implement spcoptions by just defining
> RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of
> an unsavory feeling that I'm sure someone is going to complain about
> it...  I suppose we could go through and systematically rename all
> instances of reloptions to ent(ity)options or storageoptions or
> gen(eric)options or somesuch...

Maybe I missed part of the discussion, but do these really need to be
handled like reloptions instead of like datoptions?  Perhaps the
deciding factor is that we want to parse them once and store them in a
cache, so like reloptions; the others are used once per connection and
then thrown away.

If this is the case, then I think we could just decide that their name
is reloptions due to hysterical reasons and be done with it.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Some notes about Param handling with "Oracle style" plpgsql variables
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Some notes about Param handling with "Oracle style" plpgsql variables