Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Fixes gram.y

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Rod Taylor <rbt(at)zort(dot)ca>,pgsql-patches(at)postgresql(dot)org,Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Fixes gram.y
Date: 2002-03-19 16:56:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Peter Eisentraut wrote:
> >> There is a standard for this.  CREATE DOMAIN shows CREATE DOMAIN.
> > OK, CVS changed to emit CREATE DOMAIN.
> What's standard about it?  I count 9 existing statements that use
> "CREATE", vs 4 that use "CREATE xxx".  (And of those four, CREATE
> VERSION is dead code...)  The closest existing statement, CREATE
> TYPE, emits "CREATE".
> Plain "CREATE" seems like the conforming choice, unless we'd like
> to do a wholesale revision of existing command tags.  Which is
> not necessarily an unreasonable thing to do.  But just making CREATE
> DOMAIN emit "CREATE DOMAIN" isn't improving consistency at all.

I assumed Peter meant some kind of ANSI SQL standard, but I am kind of
lost how they define that level of detail in the standard.  I agree a
wholesale cleanup there would be a good idea.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2002-03-19 17:21:26
Subject: Re: [HACKERS] Fixes gram.y
Previous:From: Tom LaneDate: 2002-03-19 16:54:44
Subject: Re: [HACKERS] Fixes gram.y

pgsql-patches by date

Next:From: Tom LaneDate: 2002-03-19 16:59:15
Subject: Re: Eurodates by default
Previous:From: Tom LaneDate: 2002-03-19 16:54:44
Subject: Re: [HACKERS] Fixes gram.y

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group