Re: Getting rid of pre-assignment of index names in CREATE TABLE LIKE

From: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Getting rid of pre-assignment of index names in CREATE TABLE LIKE
Date: 2012-07-15 18:53:08
Message-ID: CABwTF4UfjPzc-U3Ja=ShGaUR5P_ZuCcKZTBd=wdUARjNcuU3Eg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 15, 2012 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> writes:
> > On Sat, Jul 14, 2012 at 4:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I would like to sneak this fix into 9.2, though. Does anyone think
> >> it's already too late to be touching these APIs for 9.2?
>
> > I'd like us to stick to the standard practice of not changing
> features/API
> > in beta releases.
>
> This is a bug fix, not a feature addition, and sometimes you can't fix
> bugs without touching APIs that might be used by third party code.
> So the question here is whether this bug fix is sufficiently important,
> and on the other side how likely it is that anyone has already built
> extensions for 9.2 that depend on IndexStmt or DefineIndex. I don't
> think trying to treat it as a "policy" matter is helpful -- it's a
> tradeoff.
>

I was hoping that we could fix the bug in released code without having to
change the structure or the API, but if that's not feasible, I will
withdraw my objection.

> If you happen to know of EDB-private code that would be broken by
> this change, telling us so (and why a mid-beta change would be
> problematic) would be helpful.
>

I checked, and I don't see any EDB code that would be affected by this
change.

Best regards,
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-07-15 19:36:47 Re: elog/ereport noreturn decoration
Previous Message Tom Lane 2012-07-15 18:29:27 Re: [PERFORM] DELETE vs TRUNCATE explanation