| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | jam paydavousi <jampaydavousi(at)yahoo(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17498: Receive Failed: (error code 1) when importing any csv file from pgAdmin with no explanations |
| Date: | 2022-05-25 22:14:51 |
| Message-ID: | CAKFQuwYHVd_zZN3WP2zgOOfTExenqC8=1zWbvDxdBjOJ2+tn0w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, May 25, 2022 at 3:04 PM jam paydavousi <jampaydavousi(at)yahoo(dot)com>
wrote:
> Never mind I solved the problem. I had to replace 'INT' with 'BIGINT'
> forgot 10 digit mobile numbers require 8 bytes.
>
>
IMO, and that of most modellers I suspect, the use of a numeric type to
represent a non-numeric phone number is the problem. While phone numbers
typically consist of digits they are not numbers - they are identifiers.
In particular, it makes no sense to perform math operations on them. I'd
suggest you use "text" for the data type - add a check constraint if you
want to ensure the imported data meets specific criteria.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2022-05-25 22:33:19 | Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function |
| Previous Message | jam paydavousi | 2022-05-25 22:10:53 | Re: BUG #17498: Receive Failed: (error code 1) when importing any csv file from pgAdmin with no explanations |