Re: Loss of some parts of the function definition

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Sergey Grinko <sergey(dot)grinko(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Loss of some parts of the function definition
Date: 2015-04-30 13:44:19
Message-ID: CAFj8pRCs9EvXo9j9RQXpT4RiCNh4e5Bc+pWfHL80=XGe1eitEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-04-30 15:34 GMT+02:00 Sergey Grinko <sergey(dot)grinko(at)gmail(dot)com>:

> I agree that it is better to show what really works.
> I propose to allow additional option through a source code which is made
> on the basis of a compilation of metadata.
> This will solve the problem.
>

You can to teach PostgreSQL function to use precision and derived types -
it is not plpgsql issue only - it is related to all PL.

There was some proposals in this area. Currently it is much better
situation than year ago, because plpgsql use binary cast instead IO cast
now.

Regards

Pavel Stehule

>
> 2015-04-30 16:19 GMT+03:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>
>>
>>
>> 2015-04-30 15:08 GMT+02:00 Sergey Grinko <sergey(dot)grinko(at)gmail(dot)com>:
>>
>>> That's what I have to do now.
>>> But there is some problem.
>>> When you try to build the update script I get to Git code is always
>>> different from what I see in the database.
>>> It is not right.
>>> MSSQL Server, Oracle, ... always saving of the full text DDL.
>>> I do not understand why PostgreSQL believe that part of the source
>>> function must be removed !?
>>>
>>
>> I can understand to problem, but it doesn't help to you. Postgres
>> displays the code, that is really used. So we can speak what is more wrong
>> - displaying original but not used code, or displaying really used code.
>>
>> I am thinking so current solution is better - any other solution mean 2x
>> stored data, that can be partially inconsistent.
>>
>> It cannot be comparable with Oracle - because it is different technology.
>>
>>
>>>
>>> 2015-04-30 15:59 GMT+03:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>>>
>>>>
>>>>
>>>> 2015-04-30 14:52 GMT+02:00 Sergey Grinko <sergey(dot)grinko(at)gmail(dot)com>:
>>>>
>>>>> Yes, I understand that.
>>>>> So I ask to implement saving of the full text DDL.
>>>>> This will allow developers to be able to save a meaning at the level
>>>>> of the source code.
>>>>> I ask to make sure that the function pg_get_function_def () returns
>>>>> previously stored full text DDL, instead of generating input and output
>>>>> parameters based on metadata.
>>>>>
>>>>
>>>> I don't see a sense of this - usually much better is storing code to
>>>> files and using GIT and other.
>>>>
>>>> Surely, you can safe code to any custom table.
>>>>
>>>> Regards
>>>>
>>>> Pavel
>>>>
>>>>
>>>>>
>>>>> 2015-04-30 15:46 GMT+03:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> 2015-04-30 13:44 GMT+02:00 Sergey Grinko <sergey(dot)grinko(at)gmail(dot)com>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Dear developers, I have a request to you.
>>>>>>>
>>>>>>> Now create a script in the application of its function parameters
>>>>>>> and return values can be declared using %TYPE.
>>>>>>> However, when you save the script is stored inside the server only
>>>>>>> what is considered his body. Thus, we obtain:
>>>>>>> 1) loss of the custom formatting.
>>>>>>> 2) loss of communication parameters and return types with these
>>>>>>> types of fields to create the function.
>>>>>>> 3) multidimensional arrays are transformed into one-dimensional:
>>>>>>> [][] -> []
>>>>>>> 4) loss of data accuracy: numeric(n,m) -> numeric
>>>>>>>
>>>>>>> Please - how to save and restore the entire text of the definition
>>>>>>> to CREATE END; unchanged.
>>>>>>>
>>>>>>
>>>>>> I am afraid, it is not possible
>>>>>>
>>>>>> Postgres doesn't distinguish between multidimensional and one
>>>>>> dimensional arrays - multidimensional is just syntax suger, same is
>>>>>> function arguments - Postgres doesn't store precision for parameters.
>>>>>> type%TYPE is translated to target type outside plpgsql function. These
>>>>>> informations are not saved, so you cannot to take it from PostgreSQL
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Pavel Stehule
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Yours faithfully, Sergey Grinko
>>>>>>> Email: sergey(dot)grinko(at)gmail(dot)com
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Yours faithfully, Sergey Grinko
>>>>> Email: sergey(dot)grinko(at)gmail(dot)com
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Yours faithfully, Sergey Grinko
>>> Email: sergey(dot)grinko(at)gmail(dot)com
>>>
>>
>>
>
>
> --
> Yours faithfully, Sergey Grinko
> Email: sergey(dot)grinko(at)gmail(dot)com
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-04-30 13:46:19 Re: Reducing tuple overhead
Previous Message Robert Haas 2015-04-30 13:41:15 Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)