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

Re: Reserved words and delimited identifiers

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Joe Abbate" <jma(at)freedomcircle(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reserved words and delimited identifiers
Date: 2011-11-30 16:26:09
Message-ID: 4ED604C10200002500043641@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Joe Abbate <jma(at)freedomcircle(dot)com> wrote:
> On 11/30/2011 09:55 AM, Tom Lane wrote:
>> One possible solution, if you're getting type information about
>> columns from the server, is to cast the type OID to regtype and
>> let the regtype output converter make all the decisions.  It's
>> less notation than a join to pg_type anyway.
> 
> Unfortunately, Pyrseas' yamltodb gets (some) type information from
> a YAML input file, so we can't do that.  However, since user
> defined TYPEs are processed before TABLE definitions, we could
> search for TYPEs in the parallel catalogs (Python dictionaries)
> maintained in memory.  So, given this:
> 
> schema public:
>   description: standard public schema
>   table myuser:
>     columns:
>     - info:
>         type: user
>   type user:
>     attributes:
>     - name: text
>     - pass: text
> 
> we could generate the following SQL against an empty database:
> 
> CREATE TYPE "user" AS (name text,
>     pass text);
> CREATE TABLE myuser (
>     info "user");
 
You are prepared to handle the difference between char and "char", I
hope.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2011-11-30 16:39:13
Subject: Re: review: CHECK FUNCTION statement
Previous:From: Joe AbbateDate: 2011-11-30 16:21:03
Subject: Re: Reserved words and delimited identifiers

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