Thread: minor cleanup in plpgsql.sgml
Marcos Truchado <mtruchado@telefonica.net> reported this on -docs yesterday.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Attachment
Robert Treat <xzilla@users.sourceforge.net> writes:
> ! SELECT INTO users_rec * FROM users WHERE user_id=3;
> --- 986,993 ----
> ! SELECT * FROM users WHERE user_id=3 INTO users_rec;
Why do you want to change the example to disagree with the advice given
just above?
: At present, the INTO clause can appear almost anywhere in the SELECT
: statement, but it is recommended to place it immediately after the
: SELECT key word as depicted above. Future versions of PL/pgSQL may be
: less forgiving about placement of the INTO clause.
regards, tom lane
On Tue, 2003-11-25 at 11:24, Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > ! SELECT INTO users_rec * FROM users WHERE user_id=3;
> > --- 986,993 ----
> > ! SELECT * FROM users WHERE user_id=3 INTO users_rec;
>
> Why do you want to change the example to disagree with the advice given
> just above?
>
> : At present, the INTO clause can appear almost anywhere in the SELECT
> : statement, but it is recommended to place it immediately after the
> : SELECT key word as depicted above. Future versions of PL/pgSQL may be
> : less forgiving about placement of the INTO clause.
>
> regards, tom lane
guess that was an unconscious change made on my part. I tend to use that
format for writing functions since I feel it is more clear to read.
Actually if I had my druthers I'd probably remove that "advice"
entirely, but either way that change can be disregarded, but removal of
the "full_name varchar" line should still be done.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat <xzilla@users.sourceforge.net> writes: > Marcos Truchado <mtruchado@telefonica.net> reported this on -docs > yesterday. I submitted a patch for this typo to -patches 5 days ago. -Neil
Tom Lane writes: > Robert Treat <xzilla@users.sourceforge.net> writes: > > ! SELECT INTO users_rec * FROM users WHERE user_id=3; > > --- 986,993 ---- > > ! SELECT * FROM users WHERE user_id=3 INTO users_rec; > > Why do you want to change the example to disagree with the advice given > just above? > > : At present, the INTO clause can appear almost anywhere in the SELECT > : statement, but it is recommended to place it immediately after the > : SELECT key word as depicted above. Future versions of PL/pgSQL may be > : less forgiving about placement of the INTO clause. Well, that position is a strange choice. The standard syntax of SELECT INTO in embedded SQL is SELECT a, b, c INTO :x, :y, :z FROM ... This should probably be consistent. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Well, that position is a strange choice. The standard syntax of SELECT
> INTO in embedded SQL is
> SELECT a, b, c INTO :x, :y, :z FROM ...
> This should probably be consistent.
Well, I'm not wedded to the current recommendation, but we'll never be
able to clean up the current weird-hack implementation of SELECT INTO
until we can freeze the syntax somehow. The above looks at least as
reasonable as what we're currently recommending ...
regards, tom lane
Sorry Neil. I thought I recalled you submitting a similar patch, but
must have missed it in the archives and didn't see the change reflected
in cvs so assmeme'd that your change was in a different place.. :-(
Robert Treat
On Tue, 2003-11-25 at 14:04, Neil Conway wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > Marcos Truchado <mtruchado@telefonica.net> reported this on -docs
> > yesterday.
>
> I submitted a patch for this typo to -patches 5 days ago.
>
> -Neil
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Tue, 2003-11-25 at 14:24, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Robert Treat <xzilla@users.sourceforge.net> writes:
> > > ! SELECT INTO users_rec * FROM users WHERE user_id=3;
> > > --- 986,993 ----
> > > ! SELECT * FROM users WHERE user_id=3 INTO users_rec;
> >
> > Why do you want to change the example to disagree with the advice given
> > just above?
> >
> > : At present, the INTO clause can appear almost anywhere in the SELECT
> > : statement, but it is recommended to place it immediately after the
> > : SELECT key word as depicted above. Future versions of PL/pgSQL may be
> > : less forgiving about placement of the INTO clause.
>
> Well, that position is a strange choice. The standard syntax of SELECT
> INTO in embedded SQL is
>
> SELECT a, b, c INTO :x, :y, :z FROM ...
>
> This should probably be consistent.
>
Funny. That's a good argument for doing it that way, but almost the same
argument I make for putting the INTO at the end: so as to not confuse
people with the "SELECT a,b,c INTO newtable FROM oldtable" sql syntax.
In either case ISTM the existing recommendation is flawed.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat <xzilla@users.sourceforge.net> writes:
> Funny. That's a good argument for doing it that way, but almost the same
> argument I make for putting the INTO at the end: so as to not confuse
> people with the "SELECT a,b,c INTO newtable FROM oldtable" sql syntax.
> In either case ISTM the existing recommendation is flawed.
Come to think of it, I think that the motivation for the existing
recommendation was precisely to have a syntax that is visibly different
from the SQL-level SELECT INTO, with an eye to eventually allowing the
SQL construct to work too. This may not be very important though,
considering that SELECT INTO is deprecated in favor of CREATE TABLE AS.
regards, tom lane
Ummm - surely the original was correct? Chris Robert Treat wrote: > Marcos Truchado <mtruchado@telefonica.net> reported this on -docs yesterday. > > Robert Treat > > > ------------------------------------------------------------------------ > > Index: plpgsql.sgml > =================================================================== > RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v > retrieving revision 1.29 > diff -c -r1.29 plpgsql.sgml > *** plpgsql.sgml 12 Nov 2003 22:47:47 -0000 1.29 > --- plpgsql.sgml 25 Nov 2003 14:12:50 -0000 > *************** > *** 986,994 **** > <programlisting> > DECLARE > users_rec RECORD; > - full_name varchar; > BEGIN > ! SELECT INTO users_rec * FROM users WHERE user_id=3; > > IF users_rec.homepage IS NULL THEN > -- user entered no homepage, return "http://" > --- 986,993 ---- > <programlisting> > DECLARE > users_rec RECORD; > BEGIN > ! SELECT * FROM users WHERE user_id=3 INTO users_rec; > > IF users_rec.homepage IS NULL THEN > -- user entered no homepage, return "http://" > > > ------------------------------------------------------------------------ > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
The reported correction was removing the superfluous full_name varchar (which Neil Conway also reported a few days back). When i was rewriting the function, I subconsciously switched the SELECT INTO statement to the (IMHO) more legible syntax, though nothing was wrong with the previous version of that statement. Robert Treat On Tuesday 25 November 2003 20:30, Christopher Kings-Lynne wrote: > Ummm - surely the original was correct? > > Chris > > Robert Treat wrote: > > Marcos Truchado <mtruchado@telefonica.net> reported this on -docs > > yesterday. > > > > Robert Treat > > > > > > ------------------------------------------------------------------------ > > > > Index: plpgsql.sgml > > =================================================================== > > RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v > > retrieving revision 1.29 > > diff -c -r1.29 plpgsql.sgml > > *** plpgsql.sgml 12 Nov 2003 22:47:47 -0000 1.29 > > --- plpgsql.sgml 25 Nov 2003 14:12:50 -0000 > > *************** > > *** 986,994 **** > > <programlisting> > > DECLARE > > users_rec RECORD; > > - full_name varchar; > > BEGIN > > ! SELECT INTO users_rec * FROM users WHERE user_id=3; > > > > IF users_rec.homepage IS NULL THEN > > -- user entered no homepage, return "http://" > > --- 986,993 ---- > > <programlisting> > > DECLARE > > users_rec RECORD; > > BEGIN > > ! SELECT * FROM users WHERE user_id=3 INTO users_rec; > > > > IF users_rec.homepage IS NULL THEN > > -- user entered no homepage, return "http://" > > > > > > ------------------------------------------------------------------------ > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > Funny. That's a good argument for doing it that way, but almost the same
> > argument I make for putting the INTO at the end: so as to not confuse
> > people with the "SELECT a,b,c INTO newtable FROM oldtable" sql syntax.
> > In either case ISTM the existing recommendation is flawed.
>
> Come to think of it, I think that the motivation for the existing
> recommendation was precisely to have a syntax that is visibly different
> from the SQL-level SELECT INTO, with an eye to eventually allowing the
> SQL construct to work too. This may not be very important though,
> considering that SELECT INTO is deprecated in favor of CREATE TABLE AS.
I have removed the recommentation:
<para>
The <literal>INTO</> clause can appear almost anywhere in the <command>SELECT</command>
statement.
</para>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073