Обсуждение: determine client os
I didn't see a function for this, but is there a way in a postgresql query to determine the client OS? Thanks Sim
Hello There is no special function. you can parse some info from version() function. Regards Pavel Stehule 2011/6/13 Sim Zacks <sim@compulab.co.il>: > I didn't see a function for this, but is there a way in a postgresql query > to determine the client OS? > > > > Thanks > > Sim > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
On 06/13/2011 08:21 PM, Pavel Stehule wrote: > Hello > > There is no special function. > > you can parse some info from version() function. Yep, or you can use a PL/Python, PL/Perl or PL/Java function that makes the appropriate calls in that language. Any of these will probably require the use of the "untrusted" (superuser-only) version. -- Craig Ringer
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > Yep, or you can use a PL/Python, PL/Perl or PL/Java function that makes > the appropriate calls in that language. Any of these will probably > require the use of the "untrusted" (superuser-only) version. Nope, you can do this easily in trusted perl: CREATE OR REPLACE FUNCTION findos() RETURNS TEXT LANGUAGE plperl AS $$ return $^O; $$; SELECT findos(); findos - -------- linux - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201106130831 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk32AykACgkQvJuQZxSWSsjA4ACfTAqEYCuNEBgbPizAsZ0CJVlI TmAAnA73swdgs9eP252umOr+LE5SfNuw =y07O -----END PGP SIGNATURE-----
On Mon, Jun 13, 2011 at 12:31:57PM -0000, Greg Sabino Mullane wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > > Yep, or you can use a PL/Python, PL/Perl or PL/Java function that makes > > the appropriate calls in that language. Any of these will probably > > require the use of the "untrusted" (superuser-only) version. > > Nope, you can do this easily in trusted perl: > > CREATE OR REPLACE FUNCTION findos() > RETURNS TEXT > LANGUAGE plperl > AS $$ > return $^O; > $$; > > SELECT findos(); > > findos > - -------- > linux Please note that it will return os for *server*, and not *client*. Best regards, depesz
On 06/13/2011 08:35 PM, hubert depesz lubaczewski wrote: > Please note that it will return os for *server*, and not *client*. Argh, thankyou. I misread the question. Please disregard my suggestion. -- Craig Ringer
All the suggestions given are for the server OS :-( My purpose is to be able to return a correct file path to the client without it specifying the OS. Thanks Sim On 06/13/2011 05:38 PM, Craig Ringer wrote: > On 06/13/2011 08:35 PM, hubert depesz lubaczewski wrote: > >> Please note that it will return os for *server*, and not *client*. > > Argh, thankyou. I misread the question. Please disregard my suggestion. > > -- > Craig Ringer >
Sim Zacks <sim@compulab.co.il> writes:
> All the suggestions given are for the server OS :-(
> My purpose is to be able to return a correct file path to the client
> without it specifying the OS.
File path? Seems to me that even if you knew the client OS, that'd
provide next to no information about the installation pathnames of the
client software. Maybe you need to be a bit clearer about what you're
trying to accomplish.
regards, tom lane
On 06/13/2011 07:04 AM, Sim Zacks wrote: > I didn't see a function for this, but is there a way in a postgresql > query to determine the client OS? A PostgreSQL client application is something that speaks a correct protocol to the server. The server has no concept of what the client is other than the fact that it speaks a particular version of its language. It knows the IP address and port number it connected on, but that's basically it. So the idea of a query determining the client OS doesn't make sense; all it knows is what the client tells it, and the information required to connect to the server and execute queries does not include any such details. If you want information about a client to make its way into a statement run on the server, you have to drive that from the direction of the client you're using yourself. If your client is psql for example, you might pass client-side information into the program by using the -v/--set/--variable substitution mechanism, possibly combined with the SQL interpolation facility of psql. But if your client program is in another programming language, you'll have to use some facility in it to fill in this information. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
On 06/14/2011 08:19 AM, Tom Lane wrote: > Sim Zacks<sim@compulab.co.il> writes: >> All the suggestions given are for the server OS :-( >> My purpose is to be able to return a correct file path to the client >> without it specifying the OS. > File path? Seems to me that even if you knew the client OS, that'd > provide next to no information about the installation pathnames of the > client software. Maybe you need to be a bit clearer about what you're > trying to accomplish. > > regards, tom lane It is much simpler then that. My data includes file references. One table has the filename with a path placeholder and another table contains the windows and linux versions of the full path. This is for an intranet and we _always_ have the same drive letters (windows) and mount paths (linux) for every client. When the client requests data that includes a file reference, I want to send the relevant path. Sim
On 14 Jun 2011, at 8:35, Sim Zacks wrote: > It is much simpler then that. My data includes file references. > One table has the filename with a path placeholder and another table contains the windows and linux versions of the fullpath. This is for an intranet and we _always_ have the same drive letters (windows) and mount paths (linux) for everyclient. When the client requests data that includes a file reference, I want to send the relevant path. Best to solve that client-side then. That even works when a network drive is mapped to a different drive letter, becausethat _is_ going to happen. Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:737,4df7070412091158319318!
On 14/06/11 14:35, Sim Zacks wrote: > It is much simpler then that. My data includes file references. > One table has the filename with a path placeholder and another table > contains the windows and linux versions of the full path. This is for an > intranet and we _always_ have the same drive letters (windows) and mount > paths (linux) for every client. When the client requests data that > includes a file reference, I want to send the relevant path. Just send the client the relative path component under the mount point / drive letter / whatever. If your storage is mapped to "/net/myapp/files" on your Linux/unix boxes, and "Z:\" on your Windows boxes, both these paths: /mnt/myapp/files/project1/file.bin Z:/project1/file.bin ... share the same relative path component "project1/file.bin". Just send that to the client and let it concatenate the fixed prefix path to the storage root. That way you aren't hard-coding drive letters and mount points, and you only have to store paths once in the database. The client knows what OS it is and it knows where the storage root is mounted/mapped; the database server doesn't need to know. Yes, I know I showed the windows path with forward slash separators. As far as I can tell, these days doesn't care about this - it's quite happy with forward slash separators. If you find it to be a problem you can always have your Windows clients flip the separators. Trust me, your users and anyone else working on the codebase later will hate you if you try to do it the way you're proposing. I speak from horrid experience working with a (closed-source, legacy) product that did just what you want to do. It's a bad idea. If nothing else, what will you do when you have to add a phone client that has to access the files over HTTP or WebDAV requests? It's easy if you store just the relative path, but a nightmare if your DB must store full paths. Not to mention all the wasted storage space your proposed method requires. -- Craig Ringer
On Tue, Jun 14, 2011 at 09:35:52AM +0300, Sim Zacks wrote: > >Sim Zacks<sim@compulab.co.il> writes: > >>All the suggestions given are for the server OS :-( > >>My purpose is to be able to return a correct file path to the client > >>without it specifying the OS. > >File path? Seems to me that even if you knew the client OS, that'd > >provide next to no information about the installation pathnames of the > >client software. Maybe you need to be a bit clearer about what you're > >trying to accomplish. > > > > regards, tom lane > It is much simpler then that. My data includes file references. > One table has the filename with a path placeholder and another table > contains the windows and linux versions of the full path. This is for > an intranet and we _always_ have the same drive letters (windows) and > mount paths (linux) for every client. When the client requests data > that includes a file reference, I want to send the relevant path. Send both and have the client select the one it needs. If you don't want to need to know on the client side just try both. One will work. If both don't there's a problem somewhere. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
On 06/14/2011 10:29 AM, Craig Ringer wrote: > On 14/06/11 14:35, Sim Zacks wrote: > >> It is much simpler then that. My data includes file references. >> One table has the filename with a path placeholder and another table >> contains the windows and linux versions of the full path. This is for an >> intranet and we _always_ have the same drive letters (windows) and mount >> paths (linux) for every client. When the client requests data that >> includes a file reference, I want to send the relevant path. > Just send the client the relative path component under the mount point / > drive letter / whatever. > > If your storage is mapped to "/net/myapp/files" on your Linux/unix > boxes, and "Z:\" on your Windows boxes, both these paths: > > /mnt/myapp/files/project1/file.bin > Z:/project1/file.bin > > ... share the same relative path component "project1/file.bin". Just > send that to the client and let it concatenate the fixed prefix path to > the storage root. That way you aren't hard-coding drive letters and > mount points, and you only have to store paths once in the database. The > client knows what OS it is and it knows where the storage root is > mounted/mapped; the database server doesn't need to know. > > Yes, I know I showed the windows path with forward slash separators. As > far as I can tell, these days doesn't care about this - it's quite happy > with forward slash separators. If you find it to be a problem you can > always have your Windows clients flip the separators. > > Trust me, your users and anyone else working on the codebase later will > hate you if you try to do it the way you're proposing. I speak from > horrid experience working with a (closed-source, legacy) product that > did just what you want to do. It's a bad idea. If nothing else, what > will you do when you have to add a phone client that has to access the > files over HTTP or WebDAV requests? It's easy if you store just the > relative path, but a nightmare if your DB must store full paths. Not to > mention all the wasted storage space your proposed method requires. > > -- > Craig Ringer My structure is rather flexible and not bloated and we obviously don't store the entire file path per record in the database. I have a system settings table which defines mount points. I have a directories table which defines the relative path (from the mount point) for each type of document. In the table where the file reference is stored it shows #doctype#filename.ext. I have a view which puts together the full windows and linux paths for each document type. In the query that retrieves the file reference it does a replace for the specified doctype. If in the future we decide to add a web functionality, it can easily work with the same setup, using the protocol and base as the "mount point" and the path will still work correctly. Then the client just has to know how to access the link type. If I have a problem of users changing drive letters and/or mount points then I'll have a more serious issue. For the plannable future, we have a set of network standards, such as drive letter/mount path for corporate file server. We have had instances where a user changed the network point complained that something didn't work. We are very inflexible regarding that point. The answer was that if he changes the network paths then the system will not work. I don't see any practical way of being so flexible that the user can change drive letters and/or mount points and still expect file paths to work. UNCs are nice, but only work for Windows and in my experience (from a few years back) are much slower then mapped drives. Then we would need to be configured per machine instead of on the server and then if the user changes something on the machine again it will have to be reconfigured. Of all the options, I like the "This is the drive letter and mount paths that must be used if you want this application to work."
On 06/14/2011 05:54 PM, Sim Zacks wrote: > I have a system settings table which defines mount points. > I have a directories table which defines the relative path (from the > mount point) for each type of document. OK, so your clients already have all the information they need to assemble the paths themselves. You don't need the views. Hand clients the relative paths, and they can use the information from the system settings table to assemble the full path trivially. Advantages of doing it this way include: - The server doesn't need to know the client OS - The client can read the mount point or drive letter setting from the database *once* on startup and cache it. You won't send it each time with each file path, saving network I/O. It knows its own OS, so it knows which settings to read. - Queries are cheaper and simpler because there's no need for string assembly and views that use system settings tables. > In the table where the file reference is stored it shows > #doctype#filename.ext. > I have a view which puts together the full windows and linux paths for > each document type. In the query that retrieves the file reference it > does a replace for the specified doctype. So you store different document types in different mount points / drive letters? Is that why you're doing this substitution? If so: again, the client can do this substitution. It knows its own OS and can read the settings table once. (If you expect settings to change a lot you can always have clients LISTEN for NOTIFY events on change). > I don't see any practical way of being so flexible that the user can > change drive letters and/or mount points and still expect file paths to > work. If you want all-server-side configuration, then yep, you're pretty much stuck with fixed paths. Many packages I've used have a client-side config file that can be used to control path and database access settings, so clients with special needs can change paths etc. If all clients are configured the same, it's typical to put the config file on a shared volume via a UNC path. The app is invoked with a shortcut / wrapper script / environment variable / registry setting that specifies the config file path. You presumably have some minimal client configuration mechanism already so the client can discover which server to talk to. Same principle. -- Craig Ringer