On Wed, Apr 25, 2012 at 11:34 PM, Brendan Jurd <direvus@gmail.com> wrote:
> On 26 April 2012 16:02, Jeff Davis <pgsql@j-davis.com> wrote:
>> As far as I can tell, postgresql has the following object-relational
>> features:
>>
> ...
>
>> (3) Dot function call syntax: "select foo.count from foo" -- surprising
>> to most people, and I don't recall ever seeing it suggested for actual
>> use. I would go so far as to say we should deprecate this syntax,
>> because I think it's more likely to be some kind of mistake than
>> anything else.
>
> Sometime in the distant past (can't find it now), I raised the idea of
> having "methods" registered on a table. If we are to pursue the
> analogy of a table being like an object class, and a record being like
> an object instance, well we've got the attributes covered, but we
> don't have the methods. My pipedream was that these methods could be
> listed in \d and executed using dot call syntax. So you could define
> something like "FUNCTION age_years(person, date) RETURNS int" and then
> call it like:
>
> SELECT p.age_years(date '2012-05-01')
> FROM person p
>
> As I recall, my idea did not achieve escape velocity, but I still
> think it would a) extend the dot-call syntax to a more useful pattern,
> b) bolster our justification for the "O" in "ORDBMS", and c) actually
> be kind of awesome.
Dot syntax should be replaced by something less ambiguous, though.
The problem is that you currently have issues in some versions of Pg
where p.name might be the name of the person, or it might be the p
record cast as something almost identical to varchar(63)....... The
only reason this is not an issue on more recent versions of Pg is that
implicit casting to text types has been dropped so this doesn't really
address the underlying problem.
>
> On the broader question, I think you're right that our "O" is a little
> bit tenuous. But I take that as an incentive to make Postgres more
> object-y, rather than an incentive to drop the "O".
I would agree there.
Best Wishes,
Chris Travers