If the string will always be in that general form, use substring & position
functions (see "String Functions and Operators" in the docs.
Example: unit_number := substr(team_number, strpos(team_number, ''-'') + 1);
If you don't want the leading zero, you could make make the "+1" into "+2".
If you m
I think you need to use syntax:
raise exception ''Member % Not Found'', unitno;
> -Original Message-
> From: Gary Stainburn [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, July 18, 2001 10:24 AM
> To: pgsql-sql
> Subject: Re: pl/pgsql - code review + question
>
> Okay, I've been hit r
Hi Jeff,
That's sorted my exceptions out, now all I've got to do is find out why it's
not finding the record in the first place.
Gary.
On Wednesday 18 July 2001 4:48 pm, Jeff Eckermann wrote:
> I think you need to use syntax:
> raise exception ''Member % Not Found'', unitno;
>
> > -Origin
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> MY book in chapter 18 has a Pl/PgSQL function called change_statename
> that does insert/update automatically.
>
> http://www.postgresql.org/docs/awbook.html
The functions called get_details though, so I assumed it's supposed to be
shorthand for a joi
27, 2001 3:52 PM
> > To: Jeff Eckermann
> > Cc: [EMAIL PROTECTED]; wade
> > Subject:Re: [SQL] RE: pl/pgsql and returning rows
> >
> > MY book in chapter 18 has a Pl/PgSQL function called change_statename
> > that does insert/update automatically.
> >
MY book in chapter 18 has a Pl/PgSQL function called change_statename
that does insert/update automatically.
http://www.postgresql.org/docs/awbook.html
> As a workaround, you can insert your row into an existing table, then
> retrieve it from there later. I think you need to enumerate a
As a workaround, you can insert your row into an existing table, then
retrieve it from there later. I think you need to enumerate all of the
fields, as in 'INSERT INTO table VALUES (ret.field1,
ret.field2,...ret.fieldn);'. At least, I haven't succeeded any other way.
Messy, but the best method a
[ Charset ISO-8859-1 unsupported, converting... ]
> On Friday 09 February 2001 12:23, [EMAIL PROTECTED] wrote:
> > I've just spent the last day or two trying to get to grips with plpgsql and
> > can't believe how abysmal the documetentation and examples are. I've been
> > trawling through the mail
On Friday 09 February 2001 12:23, [EMAIL PROTECTED] wrote:
> I've just spent the last day or two trying to get to grips with plpgsql and
> can't believe how abysmal the documetentation and examples are. I've been
> trawling through the mailist lists and I notice there was talk back in 1999
> about
Jan Wieck <[EMAIL PROTECTED]> writes:
>> I am inclined to keep our options open by forbidding EXECUTE 'SELECT
>> INTO ...' for now. That's more than a tad annoying, because that leaves
>> no useful way to do a dynamically-built SELECT, but if we don't forbid
>> it I think we'll regret it later.
Title: RE: [SQL] Re: PL/pgsql EXECUTE 'SELECT INTO ...'
What I wrote wasn't about temp tables, it was about selecting into plpgsql variables. It would appear that Jan's syntax gets around this problem.
MikeA
-Original Message-
From: Jan Wieck [mailto:[EMAIL
Tom Lane wrote:
> I have looked a little bit at what it'd take to make SELECT INTO inside
> an EXECUTE work the same as it does in plain plpgsql --- that is, the
> INTO should reference plpgsql variables, not a destination table.
> It looks to me like this is possible but would require some nontri
Unfortunately you cannot use parameters as you like. The FROM clause
cannot contain a parameter. It must be constant.
Zoltan
--
Kov\'acs, Zolt\'an
[EMAIL PROTECTED]
http://www.math.u-szeged.hu/~kovzol
Oh yeah, I'm using v7.0
Mark
14 matches
Mail list logo
