And then what? Make the search box on 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,

----- Original Message ----- From: "Richard Huxton" <>
To: "Gregory Stark" <[EMAIL PROTECTED]>
Cc: "Andrew Hammond" <[EMAIL PROTECTED]>; <>; <>
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" <> 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?


Reply via email to