Обсуждение: Missing ColLabel tokens
I have noticed that AND and TRAILING could be made ColLabel's without further changes. Currently they are completely reserved. (This is especially odd given that OR is a ColLabel.) Would that be okay to change? (For the interested, the only other completely reserved tokens are TYPE and AS.) -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> I have noticed that AND and TRAILING could be made ColLabel's without
> further changes. Currently they are completely reserved. (This is
> especially odd given that OR is a ColLabel.) Would that be okay to
> change?
If you don't get shift/reduce conflicts, go for it.
> (For the interested, the only other completely reserved tokens are TYPE
> and AS.)
I suspect we're stuck on that for AS. However, TYPE is actually allowed
as a ColId, via the 'generic' production, so in reality it's not
reserved.
regards, tom lane
Tom Lane writes: > > (For the interested, the only other completely reserved tokens are TYPE > > and AS.) > > I suspect we're stuck on that for AS. However, TYPE is actually allowed > as a ColId, via the 'generic' production, so in reality it's not > reserved. I think this generic production might be a mistake. The productions go like this: generic ::= <ident> | TYPE ColId ::= <generic> | ... Generic ::= <generic> ConstTypename ::= <Generic> | (SQL type names) AexprConst ::= <ConstTypename> <Sconst> | ... SimpleTypename ::= <ConstTypename> | ... and then SimpleTypename is sort of a Typename. This allows TYPE to be used as a type name! All three of the statements select cast(42 as type); select type 'xxx'; create table foo (a type); fail with "ERROR: Unable to locate type name 'type' in catalog". Besides this there are no other productions making use of <generic>. I see this was introduced in gram.y 2.180, 2000-07-28, with a message of Fix acceptance of PATH as a type and column name.Note that this has changed some of the edge cases for what is acceptedasa type name and/or column id. Regression test passes, but moretweaks may be coming... which makes this look unintentional. TYPE could simply be under ColId and <generic> would simply be IDENT. Where's the harm? you might ask. I'm going to have to insert a special case into my extract-keyword-categories-from-gram.y (and make a DocBook table from it) tool. ;-) -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> I suspect we're stuck on that for AS. However, TYPE is actually allowed
>> as a ColId, via the 'generic' production, so in reality it's not
>> reserved.
> I think this generic production might be a mistake.
It looks fairly weird to me too. Seems to me that we should get rid of
token "generic", have ColId's first alternative be IDENT, add TYPE to
ColId (or possibly TokenId), and have the Generic type production accept
IDENT directly.
Thomas, why'd you do it this way?
regards, tom lane
> >> I suspect we're stuck on that for AS. However, TYPE is actually allowed
> >> as a ColId, via the 'generic' production, so in reality it's not
> >> reserved.
> > I think this generic production might be a mistake.
> It looks fairly weird to me too. Seems to me that we should get rid of
> token "generic", have ColId's first alternative be IDENT, add TYPE to
> ColId (or possibly TokenId), and have the Generic type production accept
> IDENT directly.
> Thomas, why'd you do it this way?
Hmm. I'm certain that I could not completely explain "why it is this
way" since this has all been accumulated in incremental changes over the
last 7 years ;) And I rarely feel that the current state is sufficiently
messed up to warrant larger cleanup changes -- though that has happened
at times -- so there may be some incremental additions which could be
replaced by some consolidations.
I'm not certain what specifically you are asking about wrt "why'd you do
it this way"...
It may be that "generic:" was originally there for symmetry with the
other "lowercase/uppercase" production pairs such as "character:" and
"Character:".
The CVS logs indicate that I allowed TYPE as a column name back in 1997.
The implication from the log (and my recollection) is that it would be
*nice* to have "type" allowed as a column name. And at the time, with
the existing productions, however it was done made sense for an
incremental change.
If we can clean up the grammar, great! But I'm a little worried that our
regression tests don't give sufficient coverage for some edge cases. For
example, I had found a few months ago that our CREATE TYPE productions
did not allow all SQL9x type names as arguments (if I remember the
example correctly)!
Anyway, cleanups are good, as long as they don't end up unnecessarily
restricting the set of allowed names in various contexts.
- Thomas
Tom Lane wrote: > > Peter Eisentraut <peter_e@gmx.net> writes: > > I have noticed that AND and TRAILING could be made ColLabel's without > > further changes. Currently they are completely reserved. (This is > > especially odd given that OR is a ColLabel.) Would that be okay to > > change? Would BETWEEN a AND b still work ? ----------- Hannu
Hey hackers - I'm having a bit of trouble with creating a new bootstrap system table. That is, one that is created during initdb via 'create bootstrap' in the PKI file. I realize that for this sort of system table, I need to add tuples via bootstrap DATA statements to pg_class.h, pg_attribute.h, and pg_type.h. Everything seems to work: I get the right output from initdb -d, based on analogy with all the other bootstrap tables, but the file never gets created, as if initial data for my new table never gets commited. If I add a bootstrap index on it (by hand editting the template1.bki file), I get the file, but it's empty. Everything seems to be set up right, though: I can insert data into the table once it's there. I've tried defining the structures and hand building a reldesc, in relcache.c, like the other bootstrap system tables, but that had no effect. One difference between my new table and the other system tables, perhaps, is that there is no code using the table: perhaps something with how mdopen will substitute for mdcreate, and create files while under bootstrapmode? So, is there extra trick I'm missing to getting the final commit done for an initdb bootstrap relation? If this somewhat abstract description of my problem doesn't ring a bell for anyone, I'll go ahead and generate a patch and ask for comment on it later. (I wanted to leave out details because I don't really want to discuss implementation of the specific feature until I've tried a reference implementation, myself) Ross
"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> One difference between my new table and the other system tables,
> perhaps, is that there is no code using the table: perhaps something
> with how mdopen will substitute for mdcreate, and create files while
> under bootstrapmode?
I suspect that's got something to do with it. The initialization
sequence is pretty haphazard in this area; some of the core tables are
physically created by mdopen's that occur before the associated 'create'
command from the BKI script, because the table is actually referenced by
code that executes before it's "created". Others are not, and come into
being during the 'create' the way you'd expect.
Still, it sure looks like 'create bootstrap' should cause mdcreate()
to be called, so I'm not sure why you'd see the file not get created
at all. Have you tried tracing through it with a debugger?
Do you really need the thing to be a bootstrap table, and not a plain
system table?
regards, tom lane
On Fri, Jan 05, 2001 at 06:25:38PM -0500, Tom Lane wrote: > > Still, it sure looks like 'create bootstrap' should cause mdcreate() > to be called, so I'm not sure why you'd see the file not get created > at all. Have you tried tracing through it with a debugger? > > Do you really need the thing to be a bootstrap table, and not a plain > system table? Yup, 'cause it's going to store the schema info, including the system schema. I forsee it needing to be accessed immediately during bootstrap. I was fighting with the debugger last night, and decided "I should ask, just to be sure I'm not missing something obvious..." I'll keep on that way, then. Ross
Ross J. Reedstrom writes: > > Do you really need the thing to be a bootstrap table, and not a plain > > system table? > > Yup, 'cause it's going to store the schema info, including the system > schema. I forsee it needing to be accessed immediately during bootstrap. Does "schema info" mean SQL schemas or merely additional schema information along the lines of pg_class, etc.? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Sat, Jan 06, 2001 at 03:50:03AM +0100, Peter Eisentraut wrote: > Ross J. Reedstrom writes: > > > > Do you really need the thing to be a bootstrap table, and not a plain > > > system table? > > > > Yup, 'cause it's going to store the schema info, including the system > > schema. I forsee it needing to be accessed immediately during bootstrap. > > Does "schema info" mean SQL schemas or merely additional schema > information along the lines of pg_class, etc.? > I thought that might prick your ears up. Yes, I'm looking at just how horrible it might be to implement SQL schemas. As it turns out, I think Tom is right, and I can just use a regular system table. I've got that working, and some of the gammar modified to accept the schema.table notation: now I'm working from both ends on all the places in between that need to know about the schema. Vadim's work replacing relnames with relfilenode helps to some extent. I'm taking the simplistic approach of adding the schema name wherever the relname is currently used, in parallel, and introducing a new global, the current default schema. As I said in my first note, I'm trying this out, regardless if it's the best way to implement the feature (why is it that I only seem to find time to work on new stuff in pgsql when we're in beta?) We can debate a better implementation after I have roughly working code, or have given up on it as a bad idea. As it happens, my pgsql time this week is taken up by another task, so I won't be working on this until the weekend, at the earliest. Ross