Thread: How to covert 'char' to 'inet'
Hi ! I've tried cast to convert char to inet, but that is no good waw :((. Does anybody know how to do that ? Thank you in advance. Best regards Michal
On Tue, Jul 23, 2002 at 04:29:21AM -0700, Michal O wrote: > Hi ! > I've tried cast to convert char to inet, but that is no good waw :((. > Does anybody know how to do that ? Try trim(charfield)::inet. Worked for me. I think the problem is that char is padded. A -- ---- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M6K 3E3 +1 416 646 3304 x110
I've set my date format to the following in postmaster.conf: PGDATESTYLE=NonEuropean,US THe date format is exactly how I want it but I keep getting date setting conflict errors like this one: NOTICE: Conflicting settings for date I've done SET DATESTYLE=NonEuropean,US when connected to my database as well but I still get the error. I noticed someone mentioned the -e argument for postmaster but I didn't see anything about it in man postmaster. Any help would be greatly appreciated. The reason I switched over is that the site currently accessing the database is running on IIS/ASP/VBScript and <%=Date%> records the date in this format. Thanks again, Craig S.
On Tue, 2002-07-23 at 15:40, Craig Sturman wrote: > I've set my date format to the following in postmaster.conf: > > PGDATESTYLE=NonEuropean,US > > THe date format is exactly how I want it but I keep getting date setting > conflict errors like this one: > NOTICE: Conflicting settings for date NonEuropean and US are synonyms. The first part of the DateStyle should be one of 'SQL', 'Postgres' or 'ISO'. (In the case of ISO, the European/US alternative only affects the input of dates.) -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "Finally, all of you, live in harmony with one another; be sympathetic, love as brothers, be compassionate and humble. Do not repay evil for evil or insult for insult, but with blessing, because to this you were called so that you may inherit a blessing." I Peter 3:8,9
Thank you. What I did was: inet(trim(both ' ' from server_ip::text)) and worked fine. Convertion to 'text' was needed. Do you know how time consuming it is ? Is there more efficient way ? Best regards Michal Otroszczenko > > I've tried cast to convert char to inet, but that is no good waw :((. > > Does anybody know how to do that ? > > Try trim(charfield)::inet. Worked for me. I think the problem is > that char is padded. > > A
On Wed, Jul 24, 2002 at 01:40:01AM -0700, Michal O wrote: > Thank you. What I did was: > > inet(trim(both ' ' from server_ip::text)) > > and worked fine. Convertion to 'text' was needed. > Do you know how time consuming it is ? Is there more efficient way ? No, as I say, char() is padded, and spaces (or whatever) are not legal in IP addresses. So, if you have a char field with data 10.0.0.1, its actual representation is something more like '10.0.0.1_______', where '_' is the padding. This is the same problem you would have if you inserted the char() field into a newly-created varchar() field: you'd get the padded text instead. That's a reason to avoid using char() for most cases, unless you know that the field will _always_ be the same length. A -- ---- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M6K 3E3 +1 416 646 3304 x110
If you are using IP addresses then Postgres has some really nice IP related datatypes and functions such as INET I would definately be inclined to use these instead of char() and varchar(). Darren On Thu, 25 Jul 2002, Andrew Sullivan wrote: > On Wed, Jul 24, 2002 at 01:40:01AM -0700, Michal O wrote: > > Thank you. What I did was: > > > > inet(trim(both ' ' from server_ip::text)) > > > > and worked fine. Convertion to 'text' was needed. > > Do you know how time consuming it is ? Is there more efficient way ? > > No, as I say, char() is padded, and spaces (or whatever) are not > legal in IP addresses. So, if you have a char field with data > 10.0.0.1, its actual representation is something more like > '10.0.0.1_______', where '_' is the padding. This is the same > problem you would have if you inserted the char() field into a > newly-created varchar() field: you'd get the padded text instead. > That's a reason to avoid using char() for most cases, unless you know > that the field will _always_ be the same length. > > A > > -- Darren Ferguson
On Thu, Jul 25, 2002 at 10:18:37AM -0400, Darren Ferguson <darren@crystalballinc.com> wrote a message of 38 lines which said: > If you are using IP addresses then Postgres has some really nice IP > related datatypes and functions such as INET But they do not support IPv6. See <URL:http://developer.postgresql.org/todo.php>, unfortunately.