Question about ip addr support

[deem0n]

Hi, I can not find standard class in Pharo for IPv4 and IPv6 addresses, so probably we can just use text representation for PostgreSQL type inet and friends ?

If that is accepted, I could make a PR.

[svenvc]

Hi,

It would be great to add support for more types.

Pharo, being object oriented, is better served with specific objects for each type, I think. Consider that you do not only need to parse it, but also do the right conversion the other way around (binding parameters).

Have a look in the category 'P3-Objects' where there exist many such types.

Now, for IPv4 addresses there already is a good system class, SocketAddress, that could be used.

For IPv6 one has to be added, like P3IPv6Address. If there were easy conversions with the system SocketAddress, a P3IPv4Address could be acceptable too. Or many a more general P3IPAddress class that covers both variants ?

In any case, make sure to add unit tests.

Thx,

Sven

[deem0n]

Thanks for clarification.

I respect the 'Everything is an object' approach, but don't feel brave enough to extend Pharo with good IPv4/v6 classes. And we need not only addresses, we need networks as well. See inet and cidr types.

Confusing enough, PostgreSQL inet can not be easily mapped to the Pharo SocketAddress as PostgreSQL can represent addresses and subnets in this datatype. cidr is pure subnet, so no base class in Pharo as well.

Checked GNU Smalltalk and it has something interesting: IP6Address. Probably someone could port it into the Pharo core.

For now I could go with practical approach and implement very simple P3IPv[46]Address and P3IPv[46]Network which will use textual representation. It should work fine, as PostgreSQL happily accept correct textual input format:

create table a (ip inet);
insert into a values ('10.1.2.3/32'),('10.0.0.0/8'),('::ffff:1.2.3.0/120'),('2001:4f8:3:ba:2e0:81ff:fe22:d1f1/128');
select * from a;
┌──────────────────────────────────┐
│                ip                │
├──────────────────────────────────┤
│ 10.1.2.3                         │
│ 10.0.0.0/8                       │
│ ::ffff:1.2.3.0/120               │
│ 2001:4f8:3:ba:2e0:81ff:fe22:d1f1 │
└──────────────────────────────────┘
(4 rows)

Do you think it will be acceptable for inclusion into the P3 ?

[svenvc]

I know that a good object should be more than data, of course.

But in this case, adding specific holders for the PG data types feels right to me, even if these objects would not (yet) have any useful behaviour. Having a correct interpretation of the PG data is very important as well.

Have a look in the category 'P3-Objects' where there exist many such types.

If you want and it is not too much work, you could do a PR with the code that you have, then I can have a look.

[deem0n]

Ok, thanks.

Actually, I am porting PgMetadata to P3. The project used Garage, which is not maintained and it is hard to run the code in Pharo 10. PgMetadata scans many system tables and I see ancient data types which are not supported by P3. Surely I will send PRs soon. Currently working on oidvector and "char" data types.

[svenvc]

OK, interesting. Feel free to contact me if you need more help.

Now, what I find a bit frustrating about PSQL is that the OID type space is literally infinite (you can make your own). I you start reading all kinds of system tables you encounter the strangest things indeed, I tried that too in the past.

My approach was to just start and see what happens and implement more as needed.

But it will never be enough. I wonder how other drivers deal with this open ended problem.

[deem0n]

I'm ready to add support for type "char" oid 18.

I see that bpchar 1042 is supported and mapped to Smalltalk String.

"char" is strictly one byte ASCII, but bpchar is UTF. Also, don't be confused with "char" vs char types. "char" is an ancient data type and not widely used. Modern PostgreSQL make char a magic alias for bpchar.

mi=> select 'ЦЫШ'::bpchar;
┌────────┐
│ bpchar │
├────────┤
│ ЦЫШ    │
└────────┘
(1 row)

mi=> select 'ЦЫШ'::char;
┌────────┐
│ bpchar │
├────────┤
│ Ц      │
└────────┘
(1 row)

mi=> select 'ЦЫШ'::char(3);
┌────────┐
│ bpchar │
├────────┤
│ ЦЫШ    │
└────────┘
(1 row)

mi=> select 'ЦЫШ'::"char";
┌──────┐
│ char │
├──────┤
│      │
└──────┘
(1 row)

mi=> select 'N'::"char";
┌──────┐
│ char │
├──────┤
│ N    │
└──────┘
(1 row)

The question is should I use Smalltalk Character for "char" or Smalltalk String ?

[svenvc]

Where are we on this ?

Can this issue be closed ?

[deem0n]

Seems unlikely there will be more updates on this, closing the issue.