Peter Padua Krauss wrote
> The first question is about performance: "*returns table*" have the same
> performance than "*returns record*"??
> If "yes", the *record* datatype is somewhat outdated?

Table defines the possibility to return a set while record can only ever
return a single value; so likely the set version is less performant but
regardless they have different semantics.

> I am new here, I do not know how, but I'm available to help... Can a
> future
> version of PostgreSQL implement some solution?

Craig's reply in the array post explained the reality quite well.  SQL is
strongly typed so while some improvement on the use of anonymous record
types is possible the SQL way of doing things would be to CREATE TYPE. 
Hstore and JSON provides an alternative means to define a column in a
dynamic way.  

It is unlikely that records types would ever be altered for dynamic member
access given that these types exist. But it is not impossible given a good
implementation. The one benefit is that current attempts give errors so
making it work only has to avoid performance regressions and not screw up
the parser.

As Craig said: how much does this bother you? If you cannot code C yourself
are you willing to pay someone to implement this feature?  The cost-benefit
analysis suggests this particular need is a poor area to invest resources

David J.

View this message in context:
Sent from the PostgreSQL - hackers mailing list archive at

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to