| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: About bug #6049 |
| Date: | 2011-06-03 16:19:55 |
| Message-ID: | BANLkTinpSZ-o=1rbA8T4BU28-maoHvgYxA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 3, 2011 at 12:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Jun 3, 2011 at 11:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> But anyway, there are basically two things we could do here: either
>>> allow the table alias to be referenced, or try to teach ruleutils.c
>>> not to qualify the column reference. The second looks pretty tricky
>>> and maybe not future-proof, so I'm leaning to the first. Comments?
>
>> I think that makes sense, although it would less totally arbitrary if
>> the alias were just "values" rather than "*VALUES*". The asterisks
>> suggest that the identifier is fake. But it's probably too late to do
>> anything about that.
>
> Hmm. Right now, since the identifier can't be referenced explicitly,
> you could argue that a change might be painless. But if what we're
> trying to accomplish is to allow existing view definitions of this form
> to be dumped and restored, that wouldn't work. I'm inclined to leave
> it alone.
Yep. I think we're stuck with it at this point.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2011-06-03 16:27:40 | Re: Identifying no-op length coercions |
| Previous Message | Radosław Smogura | 2011-06-03 16:19:19 | Streaming solution and v3.1 protocol |