On Wed, Feb 11, 2009 at 4:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> FWIW, I don't really buy this argument. I can't see that it's all
>> that implausible to think that the user might be able to prognosticate
>> a reasonable value for a future TOAST table.
>
> Well, it still seems to me tha
Robert Haas writes:
> FWIW, I don't really buy this argument. I can't see that it's all
> that implausible to think that the user might be able to prognosticate
> a reasonable value for a future TOAST table.
Well, it still seems to me that such a user is really more interested in
a way to set th
On Wed, Feb 11, 2009 at 3:40 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> However, Takahiro-san and Euler's position is that if you do this:
>> create table foo (f1 int) with (toast.fillfactor = 70);
>> alter table foo add column f2 text;
>> Then the toast table should have the fillfactor sett
Alvaro Herrera writes:
> Since we don't have a way to set default reloptions for main tables
> either, I don't think we should be pushing very hard for having one to
> set default reloptions for toast tables.
> Even if we were to argue that we should have both, it doesn't seem
> material for 8.4.
Tom Lane wrote:
> Or to put it another way: it seems to me that the use-case being argued
> here is really for being able to adjust the default toast reloptions.
> Not to have action at a distance on a table that doesn't exist and you
> have no way to know when you set the option what will be in i
Alvaro Herrera writes:
> However, Takahiro-san and Euler's position is that if you do this:
> create table foo (f1 int) with (toast.fillfactor = 70);
> alter table foo add column f2 text;
> Then the toast table should have the fillfactor setting.
Well, that might look sensible when phrased that w
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> I tend to think this isn't a very good idea. It's difficult for
> >> applications to know whether a toast table will be created or not.
> >> They should be able to just set the toast options and not worry.
>
> > The problem is whe
Alvaro Herrera writes:
> Tom Lane wrote:
>> I tend to think this isn't a very good idea. It's difficult for
>> applications to know whether a toast table will be created or not.
>> They should be able to just set the toast options and not worry.
> The problem is where do we store the options?
W
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> I tend to think this isn't a very good idea. It's difficult for
>>> applications to know whether a toast table will be created or not.
>>> They should be able to just set the toast options and not worry.
>>
>> The problem is
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera writes:
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
1. fillfactor.* options are silently ignored when the table doesn't have
toast relation. Should we notice the behabior to users?
ex. NOTICE: toast storage parameters are ignored
You me
Tom Lane wrote:
> Alvaro Herrera writes:
> > Alvaro Herrera wrote:
> >> ITAGAKI Takahiro wrote:
> >>> 1. fillfactor.* options are silently ignored when the table doesn't have
> >>> toast relation. Should we notice the behabior to users?
> >>> ex. NOTICE: toast storage parameters are ignored
>
> >
Alvaro Herrera writes:
> Alvaro Herrera wrote:
>> ITAGAKI Takahiro wrote:
>>> 1. fillfactor.* options are silently ignored when the table doesn't have
>>> toast relation. Should we notice the behabior to users?
>>> ex. NOTICE: toast storage parameters are ignored
>> You mean "toast.* options"? I
Alvaro Herrera wrote:
> ITAGAKI Takahiro wrote:
>
> > I tested this changes and found two issues:
> >
> > 1. fillfactor.* options are silently ignored when the table doesn't have
> >toast relation. Should we notice the behabior to users?
> >ex. NOTICE: toast storage parameters are ignored
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> IMHO the cut-and-paste way that we usually
> >> do it in pg_dump is a whole lot easier to read and maintain than this
> >> sort of ?: spaghetti.
>
> > Hmm, so should we try to get rid of them in a more consistent fashion?
>
> If y
Alvaro Herrera writes:
> Tom Lane wrote:
>> IMHO the cut-and-paste way that we usually
>> do it in pg_dump is a whole lot easier to read and maintain than this
>> sort of ?: spaghetti.
> Hmm, so should we try to get rid of them in a more consistent fashion?
If you've got the time and interest to
Tom Lane wrote:
> Alvaro Herrera writes:
> > This version should fix these issues. I refrained from adding more ? :
> > expressions because it starts getting ugly for my taste.
>
> I think you might as well just introduce two separate code paths to
> produce the 8.4 and pre-8.4 queries, so that
Alvaro Herrera writes:
> This version should fix these issues. I refrained from adding more ? :
> expressions because it starts getting ugly for my taste.
I think you might as well just introduce two separate code paths to
produce the 8.4 and pre-8.4 queries, so that you don't need the LEFT
JOIN
Tom Lane wrote:
> Alvaro Herrera writes:
> > Note that it introduces a LEFT JOIN on pg_class to itself that's always
> > present, even for server versions that do not support reloptions.
>
> Personally I'd be more worried about the unnest(). Also, please
> schema-qualify that function name; you
Peter Eisentraut writes:
> Tom Lane wrote:
>> Personally I'd be more worried about the unnest(). Also, please
>> schema-qualify that function name; you can't assume anything about
>> the search path here.
> Maybe it would be more elegant to put the search_path into proconfig?
This is psql's de
Tom Lane wrote:
Alvaro Herrera writes:
Note that it introduces a LEFT JOIN on pg_class to itself that's always
present, even for server versions that do not support reloptions.
Personally I'd be more worried about the unnest(). Also, please
schema-qualify that function name; you can't assume
Alvaro Herrera writes:
> Note that it introduces a LEFT JOIN on pg_class to itself that's always
> present, even for server versions that do not support reloptions.
Personally I'd be more worried about the unnest(). Also, please
schema-qualify that function name; you can't assume anything about
ITAGAKI Takahiro wrote:
> 2. psql's \d+ doesn't show toast storage parameters.
>
> Neither \d+ for base tables nor toast relations show toast.* parameters
> though there are some values in pg_class.reloptions.
> I think we should show toast.* parameters in \d+ for base tables
> because it has con
ITAGAKI Takahiro wrote:
> I tested this changes and found two issues:
>
> 1. fillfactor.* options are silently ignored when the table doesn't have
>toast relation. Should we notice the behabior to users?
>ex. NOTICE: toast storage parameters are ignored
>because the table
23 matches
Mail list logo
