Thread: Re: [HACKERS] when does CREATE VIEW not create a view?
See my other reply about what gets added: the problem is the rewrite rule name, as you guessed. Here's a patch that silently truncates the generated rule name. Unlike tablename or generated sequence name truncation, there's no need in normal operation for the DBA to know the name of this rule, so I didn't put in a NOTICE about the truncation. I found every accurance of _RET in the source that refered to a view rule, and patched them to do the right thing. Ross On Tue, Aug 22, 2000 at 02:21:04PM -0600, Brook Milligan wrote: > > Does the backend add something to a view identifier to push it over 32 > characters? Is that added as a prefix or a suffix? If the latter, > perhaps it should be a prefix? Or is the problem with the select rule > formed by CREATE VIEW? If the latter, should there be different > truncation rules for view names than for table names so that the > associated rule and table names have the appropriate relationship? > > Cheers, > Brook -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
Attachment
On Tue, Aug 22, 2000 at 04:05:19PM -0500, Ross J. Reedstrom wrote: > > I found every accurance of _RET in the source that refered to a view rule, > and patched them to do the right thing. Sigh. 5 minutes after sending this, I find one last one, in pg_dump. Patch attached. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
Attachment
On Wed, Aug 23, 2000 at 10:02:02AM +0900, Tatsuo Ishii wrote: > > See my other reply about what gets added: the problem is the rewrite > > rule name, as you guessed. > > > > Here's a patch that silently truncates the generated rule name. Unlike > > tablename or generated sequence name truncation, there's no need in > > normal operation for the DBA to know the name of this rule, so I didn't > > put in a NOTICE about the truncation. > > > > I found every accurance of _RET in the source that refered to a view rule, > > and patched them to do the right thing. > > Oh, the patch strikes me since it is not "multibyte aware." Are you > going to put it into the CVS? If so, please let me know after you do > it so that I could add the multibyte awareness to that. Well, I meant it to go into CVS, if noone objected. I consider your raising the multibyte issue sufficent objection to have it held off. No point patching and repatching. The problem is that I just chop it off at NAMEDATALEN, which might be in the middle of a multibyte character, correct? Ah, I see code in parser/scan.l that does the multibyte aware version of the chop. Should I just rewrite my patch with that code as a model? Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
> See my other reply about what gets added: the problem is the rewrite > rule name, as you guessed. > > Here's a patch that silently truncates the generated rule name. Unlike > tablename or generated sequence name truncation, there's no need in > normal operation for the DBA to know the name of this rule, so I didn't > put in a NOTICE about the truncation. > > I found every accurance of _RET in the source that refered to a view rule, > and patched them to do the right thing. Oh, the patch strikes me since it is not "multibyte aware." Are you going to put it into the CVS? If so, please let me know after you do it so that I could add the multibyte awareness to that. -- Tatsuo Ishii
> > Oh, the patch strikes me since it is not "multibyte aware." Are you > > going to put it into the CVS? If so, please let me know after you do > > it so that I could add the multibyte awareness to that. > > Well, I meant it to go into CVS, if noone objected. I consider your raising > the multibyte issue sufficent objection to have it held off. No point > patching and repatching. No problem for repatching I think, since we are in the development cycle anyway. > The problem is that I just chop it off at NAMEDATALEN, which might be > in the middle of a multibyte character, correct? Exactly. > Ah, I see code in parser/scan.l that does the multibyte aware version > of the chop. Should I just rewrite my patch with that code as a model? Please do so. If you need any help, please let me know. -- Tatsuo Ishii
On Tue, Aug 29, 2000 at 10:12:38AM +0900, t-ishii@sra.co.jp wrote: > > > Oh, the patch strikes me since it is not "multibyte aware." O.K. - Here's the multibyte aware version of my patch to fix the truncation of the rulename autogenerated during a CREATE VIEW. I've modified all the places in the backend that want to construct the rulename to use the MakeRetrieveViewRuleName(), where I put the #ifdef MULTIBYTE, so that's the only place that knows how to construct a view rulename. Except pg_dump, where I replicated the code, since it's a standalone binary. The only effect the enduser will see is that views with names len(name) > NAMEDATALEN-4 will fail to be created, if the derived rulename clases with an existing rule: i.e. the user is trying to create two views with long names whose first difference is past NAMEDATALEN-4 (but before NAMEDATALEN: that'll error out after the viewname truncation.) In no case will the user get left with a table without a view rule, as the current code does. > > Please do so. If you need any help, please let me know. > -- > Tatsuo Ishii I haven't tested the MULTIBYTE part. Could you give it a quick once over? Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
Attachment
Applied. > On Tue, Aug 29, 2000 at 10:12:38AM +0900, t-ishii@sra.co.jp wrote: > > > > Oh, the patch strikes me since it is not "multibyte aware." > > O.K. - > Here's the multibyte aware version of my patch to fix the truncation > of the rulename autogenerated during a CREATE VIEW. I've modified all > the places in the backend that want to construct the rulename to use > the MakeRetrieveViewRuleName(), where I put the #ifdef MULTIBYTE, so > that's the only place that knows how to construct a view rulename. Except > pg_dump, where I replicated the code, since it's a standalone binary. > > The only effect the enduser will see is that views with names len(name) > > NAMEDATALEN-4 will fail to be created, if the derived rulename clases > with an existing rule: i.e. the user is trying to create two views with > long names whose first difference is past NAMEDATALEN-4 (but before > NAMEDATALEN: that'll error out after the viewname truncation.) In no > case will the user get left with a table without a view rule, as the > current code does. > > > > > Please do so. If you need any help, please let me know. > > -- > > Tatsuo Ishii > > I haven't tested the MULTIBYTE part. Could you give it a quick once over? > > Ross > -- > Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> > NSBRI Research Scientist/Programmer > Computer and Information Technology Institute > Rice University, 6100 S. Main St., Houston, TX 77005 [ Attachment, skipping... ] -- 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, Pennsylvania 19026
I hate to say this, but this patch fails to apply on our current tree. Can you send me a version that applies? Thanks. > On Tue, Aug 29, 2000 at 10:12:38AM +0900, t-ishii@sra.co.jp wrote: > > > > Oh, the patch strikes me since it is not "multibyte aware." > > O.K. - > Here's the multibyte aware version of my patch to fix the truncation > of the rulename autogenerated during a CREATE VIEW. I've modified all > the places in the backend that want to construct the rulename to use > the MakeRetrieveViewRuleName(), where I put the #ifdef MULTIBYTE, so > that's the only place that knows how to construct a view rulename. Except > pg_dump, where I replicated the code, since it's a standalone binary. > > The only effect the enduser will see is that views with names len(name) > > NAMEDATALEN-4 will fail to be created, if the derived rulename clases > with an existing rule: i.e. the user is trying to create two views with > long names whose first difference is past NAMEDATALEN-4 (but before > NAMEDATALEN: that'll error out after the viewname truncation.) In no > case will the user get left with a table without a view rule, as the > current code does. > > > > > Please do so. If you need any help, please let me know. > > -- > > Tatsuo Ishii > > I haven't tested the MULTIBYTE part. Could you give it a quick once over? > > Ross > -- > Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> > NSBRI Research Scientist/Programmer > Computer and Information Technology Institute > Rice University, 6100 S. Main St., Houston, TX 77005 [ Attachment, skipping... ] -- 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, Pennsylvania 19026
OK, the bad news is that this does not apply to the current development tree. Ross, can you make a more corrent one? Sorry. > On Tue, Aug 29, 2000 at 10:12:38AM +0900, t-ishii@sra.co.jp wrote: > > > > Oh, the patch strikes me since it is not "multibyte aware." > > O.K. - > Here's the multibyte aware version of my patch to fix the truncation > of the rulename autogenerated during a CREATE VIEW. I've modified all > the places in the backend that want to construct the rulename to use > the MakeRetrieveViewRuleName(), where I put the #ifdef MULTIBYTE, so > that's the only place that knows how to construct a view rulename. Except > pg_dump, where I replicated the code, since it's a standalone binary. > > The only effect the enduser will see is that views with names len(name) > > NAMEDATALEN-4 will fail to be created, if the derived rulename clases > with an existing rule: i.e. the user is trying to create two views with > long names whose first difference is past NAMEDATALEN-4 (but before > NAMEDATALEN: that'll error out after the viewname truncation.) In no > case will the user get left with a table without a view rule, as the > current code does. > > > > > Please do so. If you need any help, please let me know. > > -- > > Tatsuo Ishii > > I haven't tested the MULTIBYTE part. Could you give it a quick once over? > > Ross > -- > Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> > NSBRI Research Scientist/Programmer > Computer and Information Technology Institute > Rice University, 6100 S. Main St., Houston, TX 77005 [ Attachment, skipping... ] -- 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, Pennsylvania 19026
On Mon, Oct 16, 2000 at 12:22:23PM -0400, Bruce Momjian wrote: > OK, the bad news is that this does not apply to the current development > tree. Ross, can you make a more corrent one? Sorry. I think it won't apply because it's already in there. There were also subsequent fixes to how pg_dump deals with views by Phil. Ross -- Open source code is like a natural resource, it's the result of providing food and sunshine to programmers, and then staying out of their way. [...] [It] is not going away because it has utility for both the developers and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.
On Mon, Oct 16, 2000 at 03:31:08PM -0500, Ross J. Reedstrom wrote: > On Mon, Oct 16, 2000 at 12:22:23PM -0400, Bruce Momjian wrote: > > OK, the bad news is that this does not apply to the current development > > tree. Ross, can you make a more corrent one? Sorry. > > I think it won't apply because it's already in there. There were also > subsequent fixes to how pg_dump deals with views by Phil. Err, I mean fixes by Philip to how pg_dump deals with views. AFAIK, there's no special cases in the code for views created by Philip. ;-> Ross -- Open source code is like a natural resource, it's the result of providing food and sunshine to programmers, and then staying out of their way. [...] [It] is not going away because it has utility for both the developers and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.