And then what? Make the search box on www.postgresql.org able to handle an
email address as search text without throwing a shoe?
Search for linus@torvalds.com or any other 'email' address from the postgres
home page. Barfage every time.
Easy for some isn't easy for all, apparently. Left that out as a test case
did we? Someone searching a mailing list for an email address? Who wudda
thunk it? It works without the . -- don't know why, but then I also don't
know why someone hasn't tried that before me.
"Sure, sounds like a simple solution to me..." Richard said sarcastically.
Would be funnier if the search on the website wasn't broken in a completely
stupid, almost ironic way. Ah, irony and sarcasm -- the ugly twins.
Yeah, we have to dynamically generate queries day in and day out. But then
some of us actually work for a living.
Since we already have to do that, maybe someone could make that easier?
Isn't that really the point here? Someone asked if something would be
useful, and the people who use the database to do real work said YES, and
here's how I might use it. Like full text seach and recursive queries, user
defined (fields|attributes|properties) and the ability to manage them would
be BUTTER! Is it a difficult problem? YES, but if it wasn't, why should it
be worth an advanced degree?
Or maybe 'we' only solve the trivial and obvious problems, like searching a
mailing list for an email address?
Sarcastically yours,
Sean
----- Original Message -----
From: "Richard Huxton" <dev@archonet.com>
To: "Gregory Stark" <stark@enterprisedb.com>
Cc: "Andrew Hammond" <andrew.george.hammond@gmail.com>; <josh@agliodbs.com>;
<pgsql-hackers@postgresql.org>
Sent: Monday, March 12, 2007 7:30 PM
Subject: Re: [HACKERS] My honours project - databases using dynamically
attached entity-properties
> Gregory Stark wrote:
>> "Richard Huxton" <dev@archonet.com> writes:
>>
>>> Well the cost depends on where/how complex the extra fields are. If
>>> you're just
>>> talking about adding columns usercol01..NN with different types and
>>> possibly a
>>> lookup to a single client_attributes table, it's not difficult.
>>
>> And then what? dynamically construct all your SQL queries? Sure, sounds
>> like a simple solution to me...
>
> No different to dynamically constructing a query for a report. Simpler,
> since in my experience most of these user-defined fields are just slots
> for extra codes/tags/notes rather than something you'd join on.
>
> --
> Richard Huxton
> Archonet Ltd
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>
