Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
От | Nick Rudnick |
---|---|
Тема | Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases) |
Дата | |
Msg-id | 4D487730.3000109@t-online.de обсуждение исходный текст |
Ответ на | Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases) (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | 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.stehule@gmail.com>: >> 2011/2/1 Robert Haas<robertmhaas@gmail.com>: >>> On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick<joerg.rudnick@t-online.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 >>>
В списке pgsql-hackers по дате отправления: