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/


Thu, 4 Jan 2001 21:31:11 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Missing ColLabel tokens
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

Thu, 04 Jan 2001 16:44:32 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Missing ColLabel tokens 
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 accepted
 as a type name and/or column id. Regression test passes, but more
 tweaks 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/


Thu, 4 Jan 2001 23:33:13 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: Missing ColLabel tokens 
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

Thu, 04 Jan 2001 18:25:01 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Missing ColLabel tokens 
> >> 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

Fri, 05 Jan 2001 07:24:45 +0000
Thomas Lockhart <lockhart@fourpalms.org>
Re: Missing ColLabel tokens
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

Fri, 05 Jan 2001 12:49:41 +0200
Hannu Krosing <hannu@tm.ee>
Re: Missing ColLabel tokens
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

Fri, 5 Jan 2001 16:28:07 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
bootstrap tables
"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

Fri, 05 Jan 2001 18:25:38 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: bootstrap tables 
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


Fri, 5 Jan 2001 18:48:10 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: bootstrap tables
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/


Sat, 6 Jan 2001 03:50:03 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: bootstrap tables
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

Mon, 8 Jan 2001 10:56:58 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: bootstrap tables