Thread: Re: [GENERAL] To Postgres Devs : Wouldn't changing the select limit
(switched thread to hackers)
> ... If the 'tip' is localized to a few lines, usually in
> gram.y, I don't see a reason not to help people find the right answer.
> It helps them and reduces redundant bug repots. I can't imagine a
> reason not to do it unless it starts to make our code more complex.
I'm with Peter on this one. I'd like to *not* clutter up the code and
error reporting with hints and suggestions which may or may not be to
the point.
We *should* have docs which list error messages and possible solutions,
and throwing that info into code is a poor second choice imho.
- Thomas
> (switched thread to hackers) > > > ... If the 'tip' is localized to a few lines, usually in > > gram.y, I don't see a reason not to help people find the right answer. > > It helps them and reduces redundant bug repots. I can't imagine a > > reason not to do it unless it starts to make our code more complex. > > I'm with Peter on this one. I'd like to *not* clutter up the code and > error reporting with hints and suggestions which may or may not be to > the point. > > We *should* have docs which list error messages and possible solutions, > and throwing that info into code is a poor second choice imho. Is it really clutter to add a clause and elog(). I am not advocating adding stuff like crazy, but when we see people having the same problem, it seems worth adding it. Our docs are pretty big and most people who have this type of problem are not going to know where to look in the docs. If the elog pointed them to the proper section in the docs, that would be even better, but then again, you are doing the elog at that point. What do others think? It would be good to have a specific example to discuss. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Thomas Lockhart <lockhart@fourpalms.org> writes:
> I'm with Peter on this one. I'd like to *not* clutter up the code and
> error reporting with hints and suggestions which may or may not be to
> the point.
> We *should* have docs which list error messages and possible solutions,
> and throwing that info into code is a poor second choice imho.
While you have a point in the abstract, a big difficulty is that the
docs never track the code with any accuracy. Look at the "Outputs"
portions of our existing reference pages. To the extent that they
describe possible errors at all, the information is a sad joke: out of
date in most cases, certainly incomplete in every case. Just last week
I was thinking that we should rip all that stuff out, rather than
pretend it is or ever will be accurate.
regards, tom lane
Bruce Momjian wrote: > > > (switched thread to hackers) > > > > > ... If the 'tip' is localized to a few lines, usually in > > > gram.y, I don't see a reason not to help people find the right answer. > > > It helps them and reduces redundant bug repots. I can't imagine a > > > reason not to do it unless it starts to make our code more complex. > > > > I'm with Peter on this one. I'd like to *not* clutter up the code and > > error reporting with hints and suggestions which may or may not be to > > the point. > > > > We *should* have docs which list error messages and possible solutions, > > and throwing that info into code is a poor second choice imho. > > Is it really clutter to add a clause and elog(). I am not advocating > adding stuff like crazy, but when we see people having the same problem, > it seems worth adding it. Our docs are pretty big and most people who > have this type of problem are not going to know where to look in the > docs. If the elog pointed them to the proper section in the docs, that > would be even better, but then again, you are doing the elog at that > point. > > What do others think? It would be good to have a specific example to > discuss. FWIW, Oracle has its "oerr" utility which takes the arguments: oerr facility error-code So the RDBMS generates an error code with a single line message less than or equal to 76 characters in length, prefixed by the facility and error code: ORA-01034: ORACLE not available The user can then get detailed information through the oerr utility. It would be nice, when we have error codes (are they apart of the new NLS support?), we have a "pgerr" utility to serve the same purpose. And of course the message files shipped with Oracle contain localized messages. Example output: $oerr ora 12203 12203, 00000, "TNS:unable to connect to destination" // *Cause: Invalid TNS address supplied or destination is not listening. // This error can also occur because of underlying network transport // problems. // *Action: Verify that the service name you entered on the command line // was correct. Ensure that the listener is running at the remote node and // that the ADDRESS parameters specified in TNSNAMES.ORA are correct. // Finally, check that all Interchanges needed to make the connection are // up and running. It would then be nice to have both a command-line version of the PostgreSQL equivalent and a web-based version on postgresql.org for users to use. Just my 2 cents, of course, Mike Mascari mascarm@mascari.com
Bruce Momjian wrote: > [snip] > > What do others think? Please reverse your change and go into beta quickly. regards, Hiroshi Inoue
Good day, My name is John Worsley, I'm one of the authors of the new O'Reilly PostgrSQL book. We're wrapping up the PL/pgSQL chapter's technical edit right now, but there are a couple of concerns that I was hoping someone might be able to help with. Mainly, the existing documentation on the RENAME statement seems inaccurate; it states that you can re-name variables, records, or rowtypes. However, in practice, our tests show that attempting to RENAME valid variables with: RENAME varname TO newname; ...yeilds a PL/pgSQL parse error, inexplicably. If I try the same syntax on a non-declared variable, it actually says "there is no variable" with that name in the current block, so...I think something odd is happening. :) I believe we have only gotten RENAME to work with either the NEW or OLD record variables when using PL/pgSQL with triggers, but the documentation suggests that this should be a general-purpose statement. Any assistance would be greatly appreciated. :) The RENAME statement seems kind of odd, since it seems that you could just as easily declare a general variable with the right name to begin with, and maybe that's why this isn't apparently documented anywhere else? I just want to make sure the documentation is both accurate and complete. Kind Regards, Jw. -- John Worsley, Command Prompt, Inc. jlx@commandprompt.com by way of pgsql-hackers@commandprompt.com
> Bruce Momjian wrote: > > > > [snip] > > > > > What do others think? > > Please reverse your change and go into beta quickly. I need more information. What do you want reversed, and are there enough votes to reverse those votes already made? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
"Command Prompt, Inc." <pgsql-hackers@commandprompt.com> writes:
> Mainly, the existing documentation on the RENAME statement seems
> inaccurate; it states that you can re-name variables, records, or
> rowtypes. However, in practice, our tests show that attempting to RENAME
> valid variables with:
> RENAME varname TO newname;
> ...yeilds a PL/pgSQL parse error, inexplicably. If I try the same syntax
> on a non-declared variable, it actually says "there is no variable" with
> that name in the current block, so...I think something odd is happening. :)
Yup, this is a bug. The plpgsql grammar expects varname to be a T_WORD,
but in fact the scanner will only return T_WORD for a name that is not
any known variable name. Thus RENAME cannot possibly work, and probably
never has worked.
Looks like it should accept T_VARIABLE, T_RECORD, T_ROW (at least).
T_WORD ought to draw "no such variable". Jan, I think this is your turf...
> The RENAME statement seems kind of odd, since it seems that you could just
> as easily declare a general variable with the right name to begin with,
It seems pretty useless to me too. Perhaps it's there because Oracle
has one?
regards, tom lane
Has this been addressed? --------------------------------------------------------------------------- > "Command Prompt, Inc." <pgsql-hackers@commandprompt.com> writes: > > Mainly, the existing documentation on the RENAME statement seems > > inaccurate; it states that you can re-name variables, records, or > > rowtypes. However, in practice, our tests show that attempting to RENAME > > valid variables with: > > RENAME varname TO newname; > > ...yeilds a PL/pgSQL parse error, inexplicably. If I try the same syntax > > on a non-declared variable, it actually says "there is no variable" with > > that name in the current block, so...I think something odd is happening. :) > > Yup, this is a bug. The plpgsql grammar expects varname to be a T_WORD, > but in fact the scanner will only return T_WORD for a name that is not > any known variable name. Thus RENAME cannot possibly work, and probably > never has worked. > > Looks like it should accept T_VARIABLE, T_RECORD, T_ROW (at least). > T_WORD ought to draw "no such variable". Jan, I think this is your turf... > > > The RENAME statement seems kind of odd, since it seems that you could just > > as easily declare a general variable with the right name to begin with, > > It seems pretty useless to me too. Perhaps it's there because Oracle > has one? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Has this been addressed?
No ... I punted in Jan's direction ...
regards, tom lane
Is this completed? --------------------------------------------------------------------------- > "Command Prompt, Inc." <pgsql-hackers@commandprompt.com> writes: > > Mainly, the existing documentation on the RENAME statement seems > > inaccurate; it states that you can re-name variables, records, or > > rowtypes. However, in practice, our tests show that attempting to RENAME > > valid variables with: > > RENAME varname TO newname; > > ...yeilds a PL/pgSQL parse error, inexplicably. If I try the same syntax > > on a non-declared variable, it actually says "there is no variable" with > > that name in the current block, so...I think something odd is happening. :) > > Yup, this is a bug. The plpgsql grammar expects varname to be a T_WORD, > but in fact the scanner will only return T_WORD for a name that is not > any known variable name. Thus RENAME cannot possibly work, and probably > never has worked. > > Looks like it should accept T_VARIABLE, T_RECORD, T_ROW (at least). > T_WORD ought to draw "no such variable". Jan, I think this is your turf... > > > The RENAME statement seems kind of odd, since it seems that you could just > > as easily declare a general variable with the right name to begin with, > > It seems pretty useless to me too. Perhaps it's there because Oracle > has one? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tom Lane wrote: > "Command Prompt, Inc." <pgsql-hackers@commandprompt.com> writes: > > Mainly, the existing documentation on the RENAME statement seems > > inaccurate; it states that you can re-name variables, records, or > > rowtypes. However, in practice, our tests show that attempting to RENAME > > valid variables with: > > RENAME varname TO newname; > > ...yeilds a PL/pgSQL parse error, inexplicably. If I try the same syntax > > on a non-declared variable, it actually says "there is no variable" with > > that name in the current block, so...I think something odd is happening. :) > > Yup, this is a bug. The plpgsql grammar expects varname to be a T_WORD, > but in fact the scanner will only return T_WORD for a name that is not > any known variable name. Thus RENAME cannot possibly work, and probably > never has worked. > > Looks like it should accept T_VARIABLE, T_RECORD, T_ROW (at least). > T_WORD ought to draw "no such variable". Jan, I think this is your turf... Sounds pretty much like that. Will take a look. > > > The RENAME statement seems kind of odd, since it seems that you could just > > as easily declare a general variable with the right name to begin with, > > It seems pretty useless to me too. Perhaps it's there because Oracle > has one? And I don't even remember why I've put it in. Maybe because it's an Oracle thing. This would be a cool fix, removing the damned thing completely. I like that solution :-) Anyone against removal? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com