| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(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: | 2018-11-22 15:16:34 |
| Message-ID: | af76601d-5483-d718-dda4-6222080caa21@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2018-11-22 15:20:20 | Re: [HACKERS] generated columns |
| Previous Message | Peter Eisentraut | 2018-11-22 14:54:05 | Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query |