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-16 11:39:27
Message-ID: 0CDAC834-8A28-4984-977D-6F14AF5169D3@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2010-12-16 11:48:17 Re: Instrument checkpoint sync calls
Previous Message Greg Smith 2010-12-16 11:11:38 Re: Per-column collation