From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: vacuum and row type |
Date: | 2011-06-02 16:39:54 |
Message-ID: | 3177.1307032794@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
>> I think we could just let this code assume success for type RECORD. It
>> won't affect VACUUM/ANALYZE, since there are (for reasons that should
>> now be obvious) no table or index columns of anonymous composite types.
> Of course, it's impossible to store anonymous composite type anywhere, but
> we still have possibility to use it in ORDER BY at least, following query works
> on HEAD but fails with patch:
> select ROW(1, n) as r from generate_series(1,5) as n order by r;
Right, so for type RECORD we should let the parser assume that
comparisons will work. If the anonymous composite type isn't actually
sortable, it'll fail at runtime, same as now.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-06-02 16:44:02 | Re: Please test peer (socket ident) auth on *BSD |
Previous Message | Marko Kreen | 2011-06-02 16:32:25 | Re: Please test peer (socket ident) auth on *BSD |