Skip site navigation (1) Skip section navigation (2)

Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)

From: Nick Rudnick <joerg(dot)rudnick(at)t-online(dot)de>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Date: 2011-02-01 21:12:16
Message-ID: 4D487730.3000109@t-online.de (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi Pavel,

I guess this represents most exactly what this professor is thinking 
about -- being able to create methods and types with methods which can 
be nested -- but syntactical details are of secondary importance.

All the best, Nick

On 02/01/2011 05:43 AM, Pavel Stehule wrote:
> Hello
>
> it is part of ANSi SQL 2003
>
> http://savage.net.au/SQL/sql-2003-2.bnf.html#method%20specification%20designator
>
>
> 2011/2/1 Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com>:
>> 2011/2/1 Robert Haas<robertmhaas(at)gmail(dot)com>:
>>> On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick<joerg(dot)rudnick(at)t-online(dot)de>  wrote:
>>>> Interesting... I remember that some years ago, I fiddled around with
>>>> functions, operators etc. to allow a method like syntax -- but I ever was
>>>> worried this approach would have serious weaknesses -- are there any
>>>> principal hindrances to having methods, if no, can this be implemented in a
>>>> straightforward way?
>>> It would help if you were a bit more specific.  Do you mean you want
>>> to write something like foo.bar(baz) and have that mean call the bar
>>> method of foo and pass it baz as an argument?
>>>
>>> If so, that'd certainly be possible to implement for purposes of a
>>> college course, if you're so inclined - after all it's free software -
>>> but we'd probably not make such a change to core PG, because right now
>>> that would mean call the function bar in schema baz and pass it foo as
>>> an argument.  We try not to break people's code to when adding
>>> nonstandard features.
>>>
>> I has not a standard, so I am not sure what is in standard and what
>> not. It was a popular theme about year 2000 and OOP was planed to
>> SQL3. You can find a some presentation from this time. Oracle
>> implemented these features.
>>
>> J. Melton: SQL:1999: Understanding Object-Relational and
>> Other Advanced Features, Morgan Kaufmann, 2003.
>>
>>
>> CREATE METHOD next_color (n INT)
>> RETURNS INT
>> FOR colored_part_t
>> RETURN SELF.color_id + n
>>
>> SELECT partno, color_id, DEREF(oid).next_color(1) AS next
>> FROM colored_parts
>>
>> some other databases implemented a dereferenced data (it's not only
>> Oracle's subject)
>>
>> http://www.java2s.com/Code/Oracle/Object-Oriented-Database/DEREFDereferencetheRowAddresses.htm
>>
>> Probably DB2 implements this functionality too. See doc for CREATE
>> TYPE statement, REF USING, NOT FINAL, method specification
>>
>>   CREATE TYPE  type-name
>>        ...
>>      METHOD attribute-name()
>>        RETURNS attribute-type
>>
>> these features are very nice - but is not well documented and probably not used.
>>
>> Pavel
>>
>>> --
>>> Robert Haas
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>


In response to

pgsql-hackers by date

Next:From: Nick RudnickDate: 2011-02-01 21:27:47
Subject: Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Previous:From: Kevin GrittnerDate: 2011-02-01 21:08:54
Subject: Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group