Re: proposal: auxiliary functions for record type - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: proposal: auxiliary functions for record type
Date
Msg-id 0CDAC834-8A28-4984-977D-6F14AF5169D3@phlo.org
Whole thread Raw
In response to Re: proposal: auxiliary functions for record type  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: auxiliary functions for record type  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Dec13, 2010, at 08:23 , Pavel Stehule wrote:
> There is a second possibility - and hardly simpler. We can use a
> specialised statement with own parser/executor node. Then
> implementation should be really simply
>
> syntax:
>
> EXTRACT_VALUE(expr1 FROM expr2 AS typename) ... RETURNS typename


In principle, that looks nice. I'm fairly certain, however, that
any proposal that adds special syntax just for this will very like
get shot down quickly, so I don't really want to go there.

However, I've just had an epiphany I think. Why not copy a page out
of dblink's book, and make it

select * from record_get(<record>, <field1>,  ..., <fieldn>) as (field varchar, value <type>)

The result would be
field    | value
(varchar) | (<type>)
--------------------
field1    | value1
...
fieldn    | valuen

If value1 ... value_n are able to be casted to <type>, and an error otherwise.

If dblink is able to pull that off, so should we, or am I missing
something?

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Per-column collation
Next
From: Greg Smith
Date:
Subject: Re: Instrument checkpoint sync calls