Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
2011/10/20 Valentine Gogichashvili : >> >> I suppose you could argue that selecting a value and implicitly throwing >> it away is confusing to novices, but on the other hand I've seen a whole >> lot of novices confused by the need to write PERFORM instead of SELECT. >> I think it wouldn't be an unreasonable thing to just interpret a SELECT >> with no INTO clause as being a PERFORM (ie execute and discard results). >> Then we'd not have to do anything magic for commands starting with WITH. >> >> regards, tom lane >> > > it would be really a good idea to allow SELECT without INTO in plpgsql. SELECT without INTO is useless in plpgsql - because you have to drop result. regards Pavel Stehule > PERFORM just makes things much more complicated, without actually adding any > really working "protection" from misusing SELECT without INTO. > With best regards, > -- Valentin Gogichashvili -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
On Thu, Oct 20, 2011 at 2:28 AM, Pavel Stehule wrote: >> >> it would be really a good idea to allow SELECT without INTO in plpgsql. > > SELECT without INTO is useless in plpgsql - because you have to drop result. not if you're calling a function: select func(); merlin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6262: while installing postgis in make install leavingdirectory
The following bug has been logged online: Bug reference: 6262 Logged by: Maruthi Kiran Email address: mnandi...@avineonindia.com PostgreSQL version: 8.4 Operating system: Linux Description:while installing postgis in make install leavingdirectory Details: [root@aipl-ghcvp1s postgis-1.5.3]# make install make -C liblwgeom make[1]: Entering directory `/usr/postgis-1.5.3/liblwgeom' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/postgis-1.5.3/liblwgeom' make -C postgis make[1]: Entering directory `/usr/postgis-1.5.3/postgis' Makefile.pgxs:17: warning: overriding recipe for target `install' /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:92: warning: ignoring old recipe for target `install' Makefile.pgxs:63: warning: overriding recipe for target `installdirs' /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:140: warning: ignoring old recipe for target `installdirs' Makefile.pgxs:82: warning: overriding recipe for target `uninstall' /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:164: warning: ignoring old recipe for target `uninstall' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/postgis-1.5.3/postgis' make -C loader make[1]: Entering directory `/usr/postgis-1.5.3/loader' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/postgis-1.5.3/loader' make -C utils make[1]: Entering directory `/usr/postgis-1.5.3/utils' chmod +x postgis_restore.pl create_undef.pl postgis_proc_upgrade.pl profile_intersects.pl test_estimation.pl test_joinestimation.pl make[1]: Leaving directory `/usr/postgis-1.5.3/utils' PostGIS was built successfully. Ready to install. make -C postgis install make[1]: Entering directory `/usr/postgis-1.5.3/postgis' Makefile.pgxs:17: warning: overriding recipe for target `install' /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:92: warning: ignoring old recipe for target `install' Makefile.pgxs:63: warning: overriding recipe for target `installdirs' /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:140: warning: ignoring old recipe for target `installdirs' Makefile.pgxs:82: warning: overriding recipe for target `uninstall' /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:164: warning: ignoring old recipe for target `uninstall' /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/mkinstalldirs '/usr/local/pgsql/lib' /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/install-sh -c -m 755 postgis-1.5.so '/usr/local/pgsql/lib/postgis-1.5.so' /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/install-sh -c -m 644 ./../spatial_ref_sys.sql '/usr/local/pgsql/share/contrib/postgis-1.5' /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/install-sh -c -m 644 postgis.sql '/usr/local/pgsql/share/contrib/postgis-1.5' /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/install-sh -c -m 644 uninstall_postgis.sql '/usr/local/pgsql/share/contrib/postgis-1.5' /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/install-sh -c -m 644 postgis_upgrade_15_minor.sql '/usr/local/pgsql/share/contrib/postgis-1.5' /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/install-sh -c -m 644 postgis_upgrade_14_to_15.sql '/usr/local/pgsql/share/contrib/postgis-1.5' /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/install-sh -c -m 644 postgis_upgrade_13_to_15.sql '/usr/local/pgsql/share/contrib/postgis-1.5' /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/install-sh -c -m 755 postgis-1.5.so '/usr/local/pgsql/lib/postgis-1.5.so' make[1]: Leaving directory `/usr/postgis-1.5.3/postgis' make -C loader install make[1]: Entering directory `/usr/postgis-1.5.3/loader' /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/install-sh -c pgsql2shp /usr/local/pgsql/bin /bin/sh /usr/local/pgsql/lib/pgxs/src/makefiles/../../config/install-sh -c shp2pgsql /usr/local/pgsql/bin make[1]: Leaving directory `/usr/postgis-1.5.3/loader' -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
> > > >> > >> it would be really a good idea to allow SELECT without INTO in plpgsql. > > > > SELECT without INTO is useless in plpgsql - because you have to drop > result. > > not if you're calling a function: > select func(); > > or calling bunch of functions: SELECT func(param) FROM some_subselect_with_params; or if you do not have writable CTEs yet and have a dream of calling something like: INSERT INTO some_table_with_data ... RETURNING func(some_generated_field); And, ernestly, if it were useless to have SELECT without INTO in plpgsql, there also would be no PERFORM command in plpgsql... Best regards, -- Valentine Gogichashvili
[BUGS] BUG #6263: \l causes core dump with large database
The following bug has been logged online: Bug reference: 6263 Logged by: Robert Messer Email address: bob.mes...@l-3com.com PostgreSQL version: 9.1.1 64-bit Operating system: Red Hat Enterprise Linux Server release 5.4 (Tikanga) Description:\l causes core dump with large database Details: psql.bin (9.1.1) Type "help" for help. postgres=# \l *** glibc detected *** /opt/PostgreSQL/9.1/bin/psql.bin: realloc(): invalid next size: 0x19510a20 *** === Backtrace: = /lib64/libc.so.6[0x3cb76746b4] /lib64/libc.so.6(realloc+0x102)[0x3cb76751a2] /opt/PostgreSQL/9.1/bin/../lib/libpq.so.5(enlargePQExpBuffer+0x66)[0x2b15bba 6b196] /opt/PostgreSQL/9.1/bin/../lib/libpq.so.5(appendPQExpBuffer+0xdb)[0x2b15bba6 b39b] /opt/PostgreSQL/9.1/bin/psql.bin[0x4197a5] /opt/PostgreSQL/9.1/bin/psql.bin[0x406276] /opt/PostgreSQL/9.1/bin/psql.bin[0x40e4e8] /opt/PostgreSQL/9.1/bin/psql.bin[0x4104b4] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3cb761d994] /opt/PostgreSQL/9.1/bin/psql.bin[0x403a69] === Memory map: 0040-0045b000 r-xp 08:07 1042796 /opt/PostgreSQL/9.1/bin/psql.bin 0065b000-0065c000 rw-p 0005b000 08:07 1042796 /opt/PostgreSQL/9.1/bin/psql.bin 0065c000-0065d000 rw-p 0065c000 00:00 0 194f4000-19515000 rw-p 194f4000 00:00 0 [heap] 3497e0-3497e0d000 r-xp 08:07 106 /opt/PostgreSQL/9.1/lib/liblber-2.3.so.0 3497e0d000-349800d000 ---p d000 08:07 106 /opt/PostgreSQL/9.1/lib/liblber-2.3.so.0 349800d000-349800e000 rw-p d000 08:07 106 /opt/PostgreSQL/9.1/lib/liblber-2.3.so.0 349820-349824e000 r-xp 08:07 109 /opt/PostgreSQL/9.1/lib/libncurses.so.5.5 349824e000-349844e000 ---p 0004e000 08:07 109 /opt/PostgreSQL/9.1/lib/libncurses.so.5.5 349844e000-349845c000 rw-p 0004e000 08:07 109 /opt/PostgreSQL/9.1/lib/libncurses.so.5.5 349845c000-349845d000 rw-p 349845c000 00:00 0 384340-3843418000 r-xp 08:07 1044460 /opt/PostgreSQL/9.1/lib/libsasl2.so.2 3843418000-3843618000 ---p 00018000 08:07 1044460 /opt/PostgreSQL/9.1/lib/libsasl2.so.2 3843618000-3843619000 rw-p 00018000 08:07 1044460 /opt/PostgreSQL/9.1/lib/libsasl2.so.2 3cb720-3cb721c000 r-xp 08:07 1238205 /lib64/ld-2.5.so 3cb741b000-3cb741c000 r--p 0001b000 08:07 1238205 /lib64/ld-2.5.so 3cb741c000-3cb741d000 rw-p 0001c000 08:07 1238205 /lib64/ld-2.5.so 3cb760-3cb774d000 r-xp 08:07 1238206 /lib64/libc-2.5.so 3cb774d000-3cb794d000 ---p 0014d000 08:07 1238206 /lib64/libc-2.5.so 3cb794d000-3cb7951000 r--p 0014d000 08:07 1238206 /lib64/libc-2.5.so 3cb7951000-3cb7952000 rw-p 00151000 08:07 1238206 /lib64/libc-2.5.so 3cb7952000-3cb7957000 rw-p 3cb7952000 00:00 0 3cb7a0-3cb7a82000 r-xp 08:07 1237941 /lib64/libm-2.5.so 3cb7a82000-3cb7c81000 ---p 00082000 08:07 1237941 /lib64/libm-2.5.so 3cb7c81000-3cb7c82000 r--p 00081000 08:07 1237941 /lib64/libm-2.5.so 3cb7c82000-3cb7c83000 rw-p 00082000 08:07 1237941 /lib64/libm-2.5.so 3cb7e0-3cb7e02000 r-xp 08:07 1238083 /lib64/libdl-2.5.so 3cb7e02000-3cb8002000 ---p 2000 08:07 1238083 /lib64/libdl-2.5.so 3cb8002000-3cb8003000 r--p 2000 08:07 1238083 /lib64/libdl-2.5.so 3cb8003000-3cb8004000 rw-p 3000 08:07 1238083 /lib64/libdl-2.5.so 3cb820-3cb8216000 r-xp 08:07 1238208 /lib64/libpthread-2.5.so 3cb8216000-3cb8415000 ---p 00016000 08:07 1238208 /lib64/libpthread-2.5.so 3cb8415000-3cb8416000 r--p 00015000 08:07 1238208 /lib64/libpthread-2.5.so 3cb8416000-3cb8417000 rw-p 00016000 08:07 1238208 /lib64/libpthread-2.5.so 3cb8417000-3cb841b000 rw-p 3cb8417000 00:00 0 3cb860-3cb8614000 r-xp 08:03 3147029 /usr/lib64/libz.so.1.2.3 3cb8614000-3cb8813000 ---p 00014000 08:03 3147029 /usr/lib64/libz.so.1.2.3 3cb8813000-3cb8814000 rw-p 00013000 08:03 3147029 /usr/lib64/libz.so.1.2.3 3cbba0-3cbba19000 r-xp 08:07 1237957 /lib64/libaudit.so.0.0.0 3cbba19000-3cbbc18000 ---p 00019000 08:07 1237957 /lib64/libaudit.so.0.0.0 3cbbc18000-3cbbc1a000 rw-p 00018000 08:07 1237957 /lib64/libaudit.so.0.0.0 3cbce0-3cbce0b000 r-xp 08:07 1238227 /lib64/libpam.s
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
2011/10/20 Merlin Moncure : > On Thu, Oct 20, 2011 at 2:28 AM, Pavel Stehule > wrote: >>> >>> it would be really a good idea to allow SELECT without INTO in plpgsql. >> >> SELECT without INTO is useless in plpgsql - because you have to drop result. > > not if you're calling a function: > select func(); it is correct just for void function. Pavel > > merlin > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6262: while installing postgis in make install leavingdirectory
"Maruthi Kiran" writes: > make[1]: Entering directory `/usr/postgis-1.5.3/postgis' > Makefile.pgxs:17: warning: overriding recipe for target `install' > /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:92: warning: ignoring old > recipe for target `install' > Makefile.pgxs:63: warning: overriding recipe for target `installdirs' > /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:140: warning: ignoring old > recipe for target `installdirs' > Makefile.pgxs:82: warning: overriding recipe for target `uninstall' > /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:164: warning: ignoring old > recipe for target `uninstall' > make[1]: Nothing to be done for `all'. You probably need to report that to the postgis folk, not here. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
Valentine Gogichashvili writes: > And, ernestly, if it were useless to have SELECT without INTO in plpgsql, > there also would be no PERFORM command in plpgsql... Precisely. Pavel's claim is nonsense. The only real question is how useful is it to call it PERFORM instead of SELECT. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
2011/10/20 Tom Lane : > Valentine Gogichashvili writes: >> And, ernestly, if it were useless to have SELECT without INTO in plpgsql, >> there also would be no PERFORM command in plpgsql... > > Precisely. Pavel's claim is nonsense. The only real question is how > useful is it to call it PERFORM instead of SELECT. I didn't design a PERFORM statement. There is two views - somebody from sybase's family know so SELECT without into is forwarded to client. This functionality is missing on Oracle's family. Is true so PERFORM statement is strange, but maybe it's open door for sybase's functionality that was not implemented ever. Regards Pavel Stehule > > regards, tom lane > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6263: \l causes core dump with large database
"Robert Messer" writes: > postgres=# \l > *** glibc detected *** /opt/PostgreSQL/9.1/bin/psql.bin: realloc(): invalid > next size: 0x19510a20 *** Well, this is interesting, but you're going to need to provide enough information to let someone else duplicate it. "large database" means little, and it certainly doesn't explain why you're seeing it when nobody else has reported any such thing. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6263: \l causes core dump with large database
bob.mes...@l-3com.com writes: > 2) If I replace the libedit.so with the version in this rpm: > libedit-2.11-2.20080712cvs.el5.x86_64.rpm, the command works. > 3) if I edit the psql script to use the libreadline.so that is > installed on the system (it's looking in the wrong place), the command works. In that case you're dealing with a libedit bug. libedit has a lot of known problems, especially if you're trying to use an old version as it sounds like you might be. There's not a lot we can do about that. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6263: \l causes core dump with large database
bob.mes...@l-3com.com writes: > I am talking about the one that is installed in the PostgreSQL/lib folder, > not the one from the operating system. Well, you need to be complaining to whoever provided that build of Postgres, which is not the upstream project ... and it is definitely not me personally, so replying only to me isn't going to get you anywhere. Please keep the list cc'd when replying. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6263: \l causes core dump with large database
On Oct 20, 2011, at 11:20 PM, Tom Lane wrote: > bob.mes...@l-3com.com writes: >> 2) If I replace the libedit.so with the version in this rpm: >> libedit-2.11-2.20080712cvs.el5.x86_64.rpm, the command works. > >> 3) if I edit the psql script to use the libreadline.so that is >> installed on the system (it's looking in the wrong place), the command works. > > In that case you're dealing with a libedit bug. libedit has a lot of > known problems, especially if you're trying to use an old version as > it sounds like you might be. There's not a lot we can do about that. We have tried upgrading the libedit on our buildfarms and thus the One-Click installers will now distribute newer version of libedit. Hopefully this will eliminate this error. > > regards, tom lane > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Regards, Sachin Srivastava EnterpriseDB, the Enterprise PostgreSQL company. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
Pavel Stehule writes: > I didn't design a PERFORM statement. There is two views - somebody > from sybase's family know so SELECT without into is forwarded to > client. This functionality is missing on Oracle's family. Is true so > PERFORM statement is strange, but maybe it's open door for sybase's > functionality that was not implemented ever. I cannot imagine that we'd ever make SELECT inside a plpgsql function act like that. Functions have no business directly transmitting information to the client; if they tried, they'd most likely just break the FE/BE protocol. There might be use for such a thing in a hypothetical "real stored procedure language" where the code is executing in a context entirely different from what Postgres functions run in ... but that language would be something different from plpgsql. I grant the argument that people coming from Sybase-ish DBs might be confused by this; but the current arrangement is also confusing lots of people, so I don't think that argument has all that much weight. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
On Thu, Oct 20, 2011 at 3:01 PM, Tom Lane wrote: > Pavel Stehule writes: >> I didn't design a PERFORM statement. There is two views - somebody >> from sybase's family know so SELECT without into is forwarded to >> client. This functionality is missing on Oracle's family. Is true so >> PERFORM statement is strange, but maybe it's open door for sybase's >> functionality that was not implemented ever. > > I cannot imagine that we'd ever make SELECT inside a plpgsql function > act like that. Functions have no business directly transmitting > information to the client; if they tried, they'd most likely just break > the FE/BE protocol. > > There might be use for such a thing in a hypothetical "real stored > procedure language" where the code is executing in a context entirely > different from what Postgres functions run in ... but that language > would be something different from plpgsql. small aside: I disagreed with this point a while back but I'm coming around to your point of view... merlin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
2011/10/20 Tom Lane : > Pavel Stehule writes: >> I didn't design a PERFORM statement. There is two views - somebody >> from sybase's family know so SELECT without into is forwarded to >> client. This functionality is missing on Oracle's family. Is true so >> PERFORM statement is strange, but maybe it's open door for sybase's >> functionality that was not implemented ever. > > I cannot imagine that we'd ever make SELECT inside a plpgsql function > act like that. Functions have no business directly transmitting > information to the client; if they tried, they'd most likely just break > the FE/BE protocol. > > There might be use for such a thing in a hypothetical "real stored > procedure language" where the code is executing in a context entirely > different from what Postgres functions run in ... but that language > would be something different from plpgsql. > > I grant the argument that people coming from Sybase-ish DBs might be > confused by this; but the current arrangement is also confusing lots > of people, so I don't think that argument has all that much weight. I agree with you you in almost all - Sybase-ish SELECT has sense for procedures only (in PL/pgSQL) - In SQL/PSM is natural for table functions. I disagree with Merlin or Valentine from one reason - What is sense of SELECT, that has not processed result? Is it correct from language design perspective? I can do a write a query with sense - like SELECT fx(i) FROM generate_series(1,1000) or query without sense - like SELECT 1 FROM generate_series(1,1000) - when we enable a SELECT without INTO. And there is next question - is first select a good idea - from readability perspective - in PL/pgSQL - is not better to use a SQL language?? Regards Pavel Stehule p.s. other question is implementation of PERFORM - that is it a just SELECT synonym, > > regards, tom lane > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
On Wed, Oct 5, 2011 at 1:24 AM, Dave Page wrote: > > > On Wednesday, October 5, 2011, Thomas Kellerer wrote: > > Dave Page, 04.10.2011 21:46: > > >> > >> We updated our build system to use BitRock 7 today (for unrelated > >> reasons) which has new features for ACL management. We're going to > >> investigate replacing cacls/icacls with those features tomorrow and > >> will create some test builds ASAP. > > > > If you can provide the test builds publicly, I will be happy to test them > and see if that behaves differently on my system. > > Thanks, we will. > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > As someone who recently spent a couple of days fighting with icacls, I thought I might offer some insight here. What I discovered through trial and error and much googling is that icacls has some non-intuitive behaviors which are not at all obvious from just reading the documentation. For example, it behaved entirely differently if you run it against a directory instead of a file (which may contain wildcards). The command icacls.exe C:\mydir\ (when we targeted a directory) applied to every file in C:\mydir\ and all subdirectories. icacls.exe C:\mydir\* (when we targeted a file) applied to all files in C:\, but did not apply options to files in subdirectories unless the /t switch was provided. This behavior is not directly mentioned in the documentation, but can be inferred from the first 2 examples, if you look at them carefully. Also, in the syntax description, the /t switch is shown for the icacls.exe syntax, but not for the icacls.exe syntax. I never would have noticed these if I weren't looking specifically for an explanation of the observed behavior. As far as how to use icacls to set permisions on a directory (as opposed to the files in a directory) without recursing to all subdirectories, I never did succeed in finding that out.
Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
On 10/21/2011 01:43 PM, Eric McKeeth wrote: As far as how to use icacls to set permisions on a directory (as opposed to the files in a directory) without recursing to all subdirectories, I never did succeed in finding that out. Could it depend on the presence or absence of a trailing slash? Some "interesting" commands (I'm looking at you, rsync) are guilty of changing behavior based on that. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
