From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Greg Stark <gsstark(at)mit(dot)edu>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: per-tablespace random_page_cost/seq_page_cost |
Date: | 2009-11-02 17:40:16 |
Message-ID: | 20091102174016.GC4617@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-11-02 17:42:04 | Re: Some notes about Param handling with "Oracle style" plpgsql variables |
Previous Message | Steve Atkins | 2009-11-02 17:06:00 | Re: Error on compile for Windows |