Skip site navigation (1) Skip section navigation (2)

Re: proposal: auxiliary functions for record type

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: auxiliary functions for record type
Date: 2010-12-11 20:25:44
Message-ID: 4354975A-E627-458B-8B0D-1D2E6270CD68@phlo.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Dec11, 2010, at 17:55 , Pavel Stehule wrote:
> It same trick, that I use in record_set_fields.
Oh, I see. Sorry, must haven missed that when I read your blog entry.

> But I don't want to
> use it for reading of value. I don't like it. You don't need to know a
> value, you have to know a type - NULL::type. it is just not nice :).
Well, no, it's not the most elegant API on earth, that's for sure. But I my opinion, it isn't so bad that it rectifies casting everything to text. 

> I
> though about it too, and maybe is a time for new polymorphic type
> "anytype" - and then you don't need to write a litte bit strange
> NULL::type
> 
> it can be "fieldvalue(myrec, type1, false)"
Hm, I don't think the ability to write just "type1" instead of "NULL::type1" is worth the necessary effort.

If anything, I'd allow function to use anyelement as their return value *without* having any polymorphic arguments. You'd need to surround calls to such function with a CAST() expression, unless something else determines the type. In pl/pgsql, for example, one could allow the CAST() to be skipped for assignment to variables. Then, you could write
	v_value := fieldvalue(myrec, 'f1', true)

That'd at least free you from having to specify the type in some cases. But still, even this seems to be a lot of effort for quite little gain...

best regards,
Florian Pflug


In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-12-11 21:03:23
Subject: Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records
Previous:From: Jeff JanesDate: 2010-12-11 20:18:02
Subject: Re: unlogged tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group