Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Peter Eisentraut pete...@gmx.net 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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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
Alvaro Herrera alvhe...@commandprompt.com 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.*
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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 where do we
Alvaro Herrera alvhe...@commandprompt.com 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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
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 it
Alvaro Herrera alvhe...@commandprompt.com 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
On Wed, Feb 11, 2009 at 3:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Robert Haas robertmh...@gmail.com 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
On Wed, Feb 11, 2009 at 4:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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.
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
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
Alvaro Herrera alvhe...@commandprompt.com 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
23 matches
Mail list logo
