On Thu, Jan 21, 2010 at 10:24 AM, Alex Hunsaker wrote:
> On Thu, Jan 21, 2010 at 07:30, Robert Haas wrote:
>> On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker wrote:
>>> Seems to me a comment about the above might be nice. Something like
>>> /* Things after here are should always be default null
On Thu, Jan 21, 2010 at 07:30, Robert Haas wrote:
> On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker wrote:
>> Seems to me a comment about the above might be nice. Something like
>> /* Things after here are should always be default null */ in
>> pg_attribute.h ?
>
> Well... that wouldn't actually
On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker wrote:
> Seems to me a comment about the above might be nice. Something like
> /* Things after here are should always be default null */ in
> pg_attribute.h ?
Well... that wouldn't actually be a correct summary, so no. The point
is that variable-l
On Wed, Jan 20, 2010 at 19:51, Robert Haas wrote:
> On Tue, Jan 19, 2010 at 10:51 AM, Alex Hunsaker wrote:
>> But yes, lets keep it simple for now.
>
> OK. Updated patch attached. Changes:
>
> - Incorporate your previous review patch.
> - Omit attacl and attoptions from hardcoded relation descr
On Tue, Jan 19, 2010 at 23:02, Alex Hunsaker wrote:
> On Tue, Jan 19, 2010 at 13:06, Robert Haas wrote:
>> On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
>>> ! text attoptions[1];
>> Unfortunately this change (which is obviously correct and necessary)
>> breaks the buil
On Tue, Jan 19, 2010 at 13:06, Robert Haas wrote:
> On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
>> ***
>> *** 152,158 CATALOG(pg_attribute,1249) BKI_BOOTSTRAP
>> BKI_WITHOUT_OIDS BKI_ROWTYPE_OID(75) BK
>> aclitem attacl[1];
>>
>> /* Column-level o
On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
> ***
> *** 152,158 CATALOG(pg_attribute,1249) BKI_BOOTSTRAP
> BKI_WITHOUT_OIDS BKI_ROWTYPE_OID(75) BK
> aclitem attacl[1];
>
> /* Column-level options */
> ! aclitem attoptions[1];
> } For
On Tue, Jan 19, 2010 at 07:49, Robert Haas wrote:
>That will mean that users can't use ALTER TABLE ... ALTER
> COLUMN ... SET STATISTICS DISTINCT for system tables, but I don't
> think that's much of a loss, and it certainly seems cleaner than
> hoping that any additional attoptions we add in the
On Sun, Jan 17, 2010 at 9:57 PM, Alex Hunsaker wrote:
... The idea that we want to support
attdistinct for system tables and index columns was based on a very
specific understanding of what that was going to do; for attoptions,
well, it might make sense for the options that we
On Sat, Jan 16, 2010 at 05:39, Robert Haas wrote:
> First, thanks for the review. Detailed comments/questions below.
>
> On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
>> On Sun, Jan 10, 2010 at 12:27, Robert Haas wrote:
>>> I am not very happy with ATPrepSetOptions(). I basically just
First, thanks for the review. Detailed comments/questions below.
On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
> On Sun, Jan 10, 2010 at 12:27, Robert Haas wrote:
>> I am not very happy with ATPrepSetOptions(). I basically just
>> retained the logic from ATPrepSetDistinct(), but it do
On Sun, Jan 10, 2010 at 12:27, Robert Haas wrote:
> I am not very happy with ATPrepSetOptions(). I basically just
> retained the logic from ATPrepSetDistinct(), but it doesn't really
> make sense in this context. The idea that we want to support
> attdistinct for system tables and index columns
12 matches
Mail list logo
