Re: Proposal: casts row to array and array to row

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: casts row to array and array to row
Date: 2011-10-12 07:13:59
Message-ID: CAFj8pRC2c5J_QA-45nULGOaxH67_bbfK8vz6Oe91XRR5okrpYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/10/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2011/10/11 Robert Haas <robertmhaas(at)gmail(dot)com>:
>>> On Tue, Oct 11, 2011 at 4:40 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>>> What do you think about this idea?
>
> It's a bad one.
>
>>> Well, a ROW can contain values of different types; an ARRAY can't.
>
>> yes, I know - but it should be problem only in few cases - when is not
>> possible to cast a row field to array field.
>
> This idea is basically the same as "data types don't matter", which is
> not SQL-ish and certainly not Postgres-ish.

This proposal is not about this. The data types are important and I
don't propose a universal data type or some automatic datatype. Result
of cast op has know type defined in planner time.

Proposal is more about respect to datatypes than now. A some row based
operations are based on serialization and deserialization to text.
This is in PLPerl or PLpgSQL, on user level or system level. When you
have to do some task, then you have to solve quoting, NULL
replacement, ... Casts between array and rows just remove these ugly
hacks - so work can be faster and more robust (without string
operations (when is possible) and without quoting string ops at
least).

unfortunately I am not able to solve these requests on custom
functions level, because I can't to specify a target type from
function (I am missing a some polymorphic type like "anytype").

Regards

Pavel Stehule

>
>                        regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jun Ishiduka 2011-10-12 07:27:02 Re: Online base backup from the hot-standby
Previous Message Jeff Davis 2011-10-12 06:50:28 Re: COUNT(*) and index-only scans