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
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 |