On 4/7/15 4:35 PM, Tom Lane wrote:
Jim Nasby <Jim.Nasby@xxxxxxxxxxxxxx> writes:
On 4/7/15 4:17 PM, Tom Lane wrote:
I suspect that that's only the tip of the iceberg. Remember the mess
we had with implicit casts to text? And those only existed for a dozen
or so types, not for everything. Every function or operator you define
for "variant" is going to be a loaded gun just waiting to shoot your foot
off, if you make all those casts implicit.
Yeah, that's why I avoided it. But that makes using it in a function a
real pain. :( I think this is a bit of a different scenario though,
because I don't see why you'd want to overload a function to accept both
variant and some other type.
Really what I want is for casting to variant to be a last-choice option,
and even then only for function calls, not operators. I believe that
would be safe, because then you'd have to explicitly be calling a
function, or explicitly doing something::variant = variant.
Just out of curiosity, what's the point of this type at all, compared
to "anyelement" and friends?
The two big differences are that you can store a variant in a table
(with reasonable protection against things like dropping the underlying
type out from under it), and you can readily determine what the original
type was. Well, and you're not limited to a single type in a function as
you are with polymorphic.
One place I've wanted this in the past is to allow storing settings or
other configuration in the database. Currently you're stuck either
casting everything to and from text or having a bunch of fields. With
variant you just store what you're handed.
The other thing I'm currently working on is a template system that would
allow you to use whatever type you wanted to pass data to a template
(and for the template itself), as well as allowing you to store
templates for later re-use. The nice thing about variant in this context
is that the framework itself doesn't really need to care about what's
being passed through it. If it didn't support storing templates I could
probably get away with anyelement for this; but that kinda defeats the
purpose.
I think there's a chicken and egg problem here. I've pondered variant
for several years and never thought of anything better than the case of
storing settings, which was hardly compelling enough to invest the work.
I finally decided to do it anyway just to see what would be required.
Only after I had something working did it occur to me that I could use
this to build a template system. It's certainly possible that there
isn't all that compelling of a case for variants afterall, but I don't
think they'll get a fair shake unless there's something available that's
pretty workable. I suspect there's actually some rather interesting
things it could be used for if people start thinking about it.
Your question does raise an interesting thought though... is there some
way I could leverage the polymorphic system here? I did experiment with
having functions accept anyelement instead of a variant and had some
success with that (though IIRC plpgsql tended to revolt when trying to
assign that to a variant in older versions).
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
