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 [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]>
Cc: "Andrew Hammond" <[EMAIL PROTECTED]>; <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 [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
