Re: "anyelement2" pseudotype

From: Tom Dunstan <pgsql(at)tomd(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Matt Miller <pgsql(at)mattmillersf(dot)fastmail(dot)fm>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "anyelement2" pseudotype
Date: 2007-02-16 23:33:24
Message-ID: 45D63F44.5060409@tomd.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> So it seems neither can_coerce_type() nor find_coercion_pathway() are
> really particularly well thought out in terms of what they test or don't
> test. I'm not very sure what a good refactoring would look like,
> but I am sure that I don't want all their call sites having to
> individually account for ANYfoo types. Any thoughts?

Yeah, I remember thinking at the time that some of it was a bit
backwards, but it's been almost 6 months since I did the original enum
patch, so I'll need to refresh my memory. I'll have a look over the
weekend and see if I can come up with something that'll work for these
various cases. To begin with I'll need to do a survey of the call sites
to see what they really need, since perhaps it isn't what the coerce
functions are currently offering. :) I completely agree that anything
requiring call sites to understand specifics about ANY* types is a bad
idea, the most that we would want would be a generic IsGeneric(typoid)
macro, but it would be nice to hide that inside a coerce function as
well. We'll see.

Cheers

Tom

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message FAST PostgreSQL 2007-02-16 23:34:59 WIP patch - INSERT-able log statements
Previous Message Chris Browne 2007-02-16 23:30:47 Re: autovacuum next steps