From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Per-column collation, work in progress |
Date: | 2010-10-21 20:31:50 |
Message-ID: | AANLkTimozUaHHB3-q_4m3C3NgaWijTJkYm8aS+sqvq3q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 21, 2010 at 4:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> We already have TypeName as a structure that contains type and typmod
>> (and collation, in my patch). We could make that a primnode instead of
>> a parsenode, and use it in more places, or we could make a new leaner
>> structure that only contains the numeric info.
>
> TypeName per se is completely inappropriate for use beyond the first
> stage of parsing, because it requires catalog lookups to make any sense
> of. I think the post-parsing representation should still start with a
> type OID. I can agree with replacing typmod with a struct, though.
I think we should have both the type OID and the typmod in the struct.
Carrying the type OID separately from the typmod has caused us enough
heartache already. No?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-10-21 20:39:43 | Re: Per-column collation, work in progress |
Previous Message | Tom Lane | 2010-10-21 20:28:52 | Re: Per-column collation, work in progress |