Define this as function:
SELECT COUNT(t.techid)
FROM ticket t
WHERE t.techid = $1
Then use this
SELECT u.idnum, u.username, func(u.idnum)
FROM users u;
--
The reboots are for hardware upgrades!
"http://www.nmmm.nu; <[EMAIL PROTE
> [EMAIL PROTECTED] wrote:
> >
> > Hi Sheila,
> >
> > For general database design considerations (not specific to Postgres) I
> > disagree with the others on the use of serials and sequences. These
> > things never migrate well from platform to platform, they often break, and
> > dealing with t
And here's the description of the "high-low" algorithm for
programs to create unique id's in a multi-user environement.
*** Structure of the identifier ***
Contents of the identifier:
a) session-id
b) current number within session
c) class id
These are three numbers. You may create a uniq
> 2) good books, like " C++ object databases" (David Jordan) has
> a lot material.
As an example:
Cattel, "The Object Database Standard ODMG 2.0"
Morgan Kaufmann, ISBN 1 - 55860 - 463 -4
Marten Feldtmann
either way, I do not think it's "programmatic", I assume
nobody think they are?
On Mon, 7 Feb 2000, Ross J. Reedstrom wrote:
> On Mon, Feb 07, 2000 at 01:37:21PM -0600, Ed Loehr wrote:
> > [EMAIL PROTECTED] wrote:
> > >
> > > and, it seems not "programmatically at all.
> >
> > What would make
On Mon, Feb 07, 2000 at 01:37:21PM -0600, Ed Loehr wrote:
> [EMAIL PROTECTED] wrote:
> >
> > and, it seems not "programmatically at all.
>
> What would make it "programmatic" in my view would be calling a
> function, as in "$newID = GetNewID()", prior to INSERT and then using
> the returned ID v
[EMAIL PROTECTED] wrote:
>
> On Mon, 7 Feb 2000, Ed Loehr wrote:
>
> > These are resolvable problems. One way to do a programmatic ID
> > generation as David B. suggests is to have a DB server whose purpose
> > is to issue "seed numbers" which designate, through use of a
> > pre-determined mult
"Ross J. Reedstrom" wrote:
>
> > ... One way to do a programmatic ID
> > generation as David B. suggests is to have a DB server whose purpose
> > is to issue "seed numbers" which designate, through use of a
> > pre-determined multiplier, a *range* of allocated IDs guaranteed to be
> > unique acr
Simon Drabble wrote:
I agree with everything Simon says (hmmm, there's a game in that) and
would add:
It's very likely that at some time you will change your database design
such that you will want to add or remove a field or two that uniquely
identify the record (hmmm, person's first and last n