I wrote:
> Attached is a WIP patch for addressing the problems mentioned in this
> thread:
> http://archives.postgresql.org/pgsql-hackers/2009-12/msg01764.php
> ...
> There is one thing that is not terribly nice about the behavior, which
> is that CREATE TABLE LIKE INCLUDING INDEXES is unable to generate smart
> names for expression indexes;
> ...
> The reason for this is that the patch depends on FigureColname which
> works on untransformed parse trees, and we don't have access to such
> a tree when copying an existing index. There seem to be three possible
> responses to that:
> ...
> 3. Implement a separate FigureIndexColname function that works as much
> like FigureColname as it can, but takes a transformed parse tree.
I fooled around with this solution and decided that it is a lot messier
than it's worth.
In the first place, we can't make a FigureColname-like function that
just takes a transformed tree: there is no way to interpret Vars without
some context. You need at least a table OID, and more than that if
you'd like to handle cases like multiple-relation expressions or
non-RELATION RTEs. For the case at hand of index expressions, a table
OID would be enough, but that doesn't leave much room for imagining the
function could be used for anything else in future. Worse, for the
problematic case (CREATE TABLE LIKE) we actually do not have a table OID
because the target table doesn't exist yet. We could finesse that by
passing the source table's OID instead, but that seems pretty klugy
itself.
In the second place, the number of "corner cases" where we'd generate
output different from FigureColname is much greater than I realized.
As an example, if foo is a type name then foo(x) and x::foo produce
the same parsed tree, but FigureColname will treat them differently.
Seeing that CREATE TABLE LIKE doesn't try to reproduce the source table's
index names anyway, I'm inclined to just go with the patch as-is and not
try to make it handle this one case nicely.
regards, tom lane
