From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com> |
Subject: | Re: [HACKERS] generated columns |
Date: | 2019-01-16 17:02:35 |
Message-ID: | CA+Tgmobxc5YBAPc1W4C6LuV=inzGtwu78sVeP+8Fh4pRWJQbbw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 22, 2018 at 10:16 AM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 15/11/2018 15:10, Robert Haas wrote:
> > I don't have a strong position on 1 vs. 2 vs. 3, but I do think it
> > would be nicer not to use '\0' as a column value. I'd suggest you use
> > 'n' or '0' or '-' or some other printable character instead.
>
> I had carefully considered this when attidentity was added. Using '\0'
> allows you to use this column as a boolean in C code, which is often
> convenient. Also, there are numerous places where a pg_attribute form
> or a tuple descriptor is initialized to all zeroes, which works well for
> most fields, and adding one exception like this would create a lot of
> extra work and bloat the patch and create potential for future
> instability. Also note that a C char '\0' is represented as '' (empty
> string) in SQL, so this also creates a natural representation in SQL.
I'm not really convinced. I think that the stdbool work you've been
doing shows that blurring the line between char and bool is a bad
idea. And I believe that on general principle, anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-01-16 17:10:07 | Re: Use an enum for RELKIND_*? |
Previous Message | Andrew Gierth | 2019-01-16 17:02:07 | parseCheckAggregates vs. assign_query_collations |