Re: per-tablespace random_page_cost/seq_page_cost - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: per-tablespace random_page_cost/seq_page_cost
Date
Msg-id 20091102174016.GC4617@alvh.no-ip.org
Whole thread Raw
In response to Re: per-tablespace random_page_cost/seq_page_cost  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: per-tablespace random_page_cost/seq_page_cost
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Some notes about Param handling with "Oracle style" plpgsql variables
Next
From: Robert Haas
Date:
Subject: Re: Some notes about Param handling with "Oracle style" plpgsql variables