Re: [HACKERS] WIP: to_char, support for EEEE format
2009/7/24 Euler Taveira de Oliveira eu...@timbira.com: Here is my review. The patch applied without problems. The docs and regression tests are included. Both of them worked as expected. Also, you included a fix in RN format, do it in another patch. Well, I updated an error message for RN to keep it consistent with the change I made to the nearby error message. Neither RN or is supported for input, and the error messages were vague on this point (they just said not supported). I understand that separate improvements should be submitted as separate patches, but this is really part of the one improvement. Implementing required improving the error messages, and consistency required that we improve the RN error message also. The behavior is not the same as Oracle. Oracle accepts an invalid scientific notation '999.9'. Will we support it too? I think so. euler=# SELECT to_char(1234.56789, '999.9'); ERRO: invalid format for scientific notation DETALHE: requires exactly one digit before the decimal point. DICA: For example, 9.999 is a valid format. TO_CHAR(1234.56789,'999.9') --- 1.2E+03 *shakes fist at Oracle* yes, I suppose we had better follow suit. The '9.999' format error message is misleading. euler=# select to_char(123, '9.999'); ERRO: cannot use twice Ah, thanks for picking up on this. This was a bug in the original patch. Looks like we forgot to update the formatting keyword for lowercase e. You could include an example in manual too. You could add the two failing cases above in regression tests too. I had already added an example to the manual. Please find attached version 4 of the patch, and incremental diff from version 3. It fixes the bug ( is now accepted as a valid form of ), and lifts the restriction on only having one digit before the decimal point. Cheers, BJ _4.diff.bz2 Description: BZip2 compressed data _3-to-4.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Determining client_encoding from client locale
On Fri, Jul 24, 2009 at 2:23 AM, Magnus Hagandermag...@hagander.net wrote:
1) it introduces a dependency for -lpgport when compiling a client
that uses libpq
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01511.php
For other parts of libpgport that are needed, we pull in the
individual source files. We specifically *don't* link libpq with
libpgport, for a reason. There's a comment in the Makefile that
explains why.
ok, attached a version that modifies src/interfaces/libpq/Makefile to
push chklocale.o and eliminate the dependency on libpgport, this
change also fixes the compile problem on windows
still, i'm not sure this patch is doing anything useful... i
initialized a cluster with utf8 and my system is using utf8 but when
executing my test script with client_encoding=auto it gets SQL_ASCII
postg...@casanova1:~/pg_releases/pgtests$ locale
LANG=es_EC.UTF-8
LC_CTYPE=es_EC.UTF-8
LC_NUMERIC=es_EC.UTF-8
LC_TIME=es_EC.UTF-8
LC_COLLATE=es_EC.UTF-8
LC_MONETARY=es_EC.UTF-8
LC_MESSAGES=es_EC.UTF-8
LC_PAPER=es_EC.UTF-8
LC_NAME=es_EC.UTF-8
LC_ADDRESS=es_EC.UTF-8
LC_TELEPHONE=es_EC.UTF-8
LC_MEASUREMENT=es_EC.UTF-8
LC_IDENTIFICATION=es_EC.UTF-8
LC_ALL=
postg...@casanova1:~/pg_releases/pgtests$ ./test-libpq
'dbname=postgres port=54329 client_encoding=auto'
client_encoding: SQL_ASCII
and when executing the same script compiled in windows i get an error,
it doesn't recognize the client_encoding option...
$ ./test-libpq.exe dbname=postgres user=postgres host=192.168.204.101
port=54329 client_encoding=latin1
Connection to database failed: invalid connection option client_encoding
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
Index: doc/src/sgml/libpq.sgml
===
RCS file: /home/postgres/pgrepo/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.289
diff -c -r1.289 libpq.sgml
*** doc/src/sgml/libpq.sgml 28 May 2009 20:02:10 - 1.289
--- doc/src/sgml/libpq.sgml 25 Jul 2009 00:54:11 -
***
*** 236,241
--- 236,254
/listitem
/varlistentry
+ varlistentry id=libpq-connect-client-encoding xreflabel=client_encoding
+ termliteralclient_encoding/literal/term
+ listitem
+ para
+ Character encoding to use. This sets the varnameclient_encoding/varname
+ configuration option for this connection. In addition to the values
+ accepted by the corresponding server option, you can use 'auto' to
+ determine the right encoding from the current locale in the client
+ (LC_CTYPE environment variable on Unix systems).
+ /para
+ /listitem
+ /varlistentry
+
varlistentry id=libpq-connect-options xreflabel=options
termliteraloptions/literal/term
listitem
***
*** 5871,5876
--- 5884,5899
linkend=libpq-connect-connect-timeout connection parameter.
/para
/listitem
+
+ listitem
+ para
+ indexterm
+primaryenvarPGCLIENTENCODING/envar/primary
+ /indexterm
+ envarPGCLIENTENCODING/envar behaves the same as xref
+ linkend=libpq-connect-client-encoding connection parameter.
+ /para
+ /listitem
/itemizedlist
/para
***
*** 5907,5923
listitem
para
indexterm
-primaryenvarPGCLIENTENCODING/envar/primary
- /indexterm
- envarPGCLIENTENCODING/envar sets the default client character
- set encoding. (Equivalent to literalSET client_encoding TO
- .../literal.)
- /para
- /listitem
-
- listitem
- para
- indexterm
primaryenvarPGGEQO/envar/primary
/indexterm
envarPGGEQO/envar sets the default mode for the genetic query
--- 5930,5935
Index: src/bin/psql/command.c
===
RCS file: /home/postgres/pgrepo/pgsql/src/bin/psql/command.c,v
retrieving revision 1.206
diff -c -r1.206 command.c
*** src/bin/psql/command.c 11 Jun 2009 14:49:07 - 1.206
--- src/bin/psql/command.c 25 Jul 2009 00:54:11 -
***
*** 1239,1246
while (true)
{
! n_conn = PQsetdbLogin(host, port, NULL, NULL,
! dbname, user, password);
/* We can immediately discard the password -- no longer needed */
if (password)
--- 1239,1245
while (true)
{
! n_conn = PSQLconnect(host, port, dbname, user, password);
/* We can immediately discard the password -- no longer needed */
if (password)
Index: src/bin/psql/common.c
===
RCS file: /home/postgres/pgrepo/pgsql/src/bin/psql/common.c,v
retrieving revision 1.142
diff -c -r1.142 common.c
*** src/bin/psql/common.c 11 Apr 2009 18:38:54 - 1.142
--- src/bin/psql/common.c 25 Jul 2009
Re: [HACKERS] autogenerating headers bki stuff
On Tuesday 30 June 2009 06:59:51 Robert Haas wrote:
The attached patch merges all of the logic currently in genbki.sh and
Gen_fmgrtab.{sh,pl} into a single script called gen_catalog.pl. It
then extends that logic to generate all of the Anum_* and Natts_*
constants, as well as the Schema_pg_* declarations for the bootstrap
tables.
I see a potential problem with the introduction of the catalog/anum.h header,
to hold the Anum_... defines. This looks like it could be a significant break
in the backend API, as evidenced by the fact that plperl and dblink no longer
compile with this change.
I think a less invasive change would be to include anum.h into all the
catalog/pg_*.h headers, so that the external interface stays the same.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: More portable way to support 64bit platforms
On Sat, Jul 25, 2009 at 02:24, Dave Pagedp...@pgadmin.org wrote: On Fri, Jul 24, 2009 at 10:53 PM, Stephen Frostsfr...@snowman.net wrote: Dave, * Dave Page (dp...@pgadmin.org) wrote: On Fri, Jul 24, 2009 at 10:35 PM, Stephen Frostsfr...@snowman.net wrote: Do you need access to a Win64 box? I can provide you access to a Win64 system, which Dave Page and Magnus already have access to, if it would be useful.. I haven't got round to installing a build env on there yet btw. Anything we can do to help..? If you can tell us what you'd like installed, I can probably have someone install it, provided it's not horribly complicated. :) Well, if you have a spare few minutes, VC++ 2005 Express, and the platform SDK would be useful. IIRC, there is no 64-bit support in VC++2005 Express. There is a 64-bit compiler in the SDK though, that can probably be made to work with it. I think the official support for this (SDK compiler integrated with VC++ Express) only arrived in 2008. I don't know how much work it would be though, so it would seem it's worth a try :-) But the integration of 64-bit is one of the reasons they claim for buying the full version. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: More portable way to support 64bit platforms
On Sat, Jul 25, 2009 at 9:18 AM, Magnus Hagandermag...@hagander.net wrote: IIRC, there is no 64-bit support in VC++2005 Express. There is a 64-bit compiler in the SDK though, that can probably be made to work with it. I think the official support for this (SDK compiler integrated with VC++ Express) only arrived in 2008. I don't know how much work it would be though, so it would seem it's worth a try :-) But the integration of 64-bit is one of the reasons they claim for buying the full version. That rings a bell actually. No problem - we can just compile on the command line, -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: More portable way to support 64bit platforms
On Sat, Jul 25, 2009 at 10:35, Dave Pagedp...@pgadmin.org wrote: On Sat, Jul 25, 2009 at 9:18 AM, Magnus Hagandermag...@hagander.net wrote: IIRC, there is no 64-bit support in VC++2005 Express. There is a 64-bit compiler in the SDK though, that can probably be made to work with it. I think the official support for this (SDK compiler integrated with VC++ Express) only arrived in 2008. I don't know how much work it would be though, so it would seem it's worth a try :-) But the integration of 64-bit is one of the reasons they claim for buying the full version. That rings a bell actually. No problem - we can just compile on the command line, You still need vcbuild, which I don't believe ships with the platform sdk. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] DefaultACLs
Joshua Tolley wrote: Am I the only one that gets this on make check, with this version (from src/test/regress/log/initdb.log): selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /home/josh/devel/pgsrc/pg85/src/test/regress/./tmp_check/data/base/1 ... FATAL: relation pg_namespace_default_acl already exists child process exited with exit code 1 initdb: data directory /home/josh/devel/pgsrc/pg85/src/test/regress/./tmp_check/data not removed at user's request Certainly never happened to me. Are you using any special parameters or something (altho I don't have the slightest idea what could cause that) ? I run make check on patches using gcc under debian and msvc on vista before sending them. -- Regards Petr Jelinek (PJMODOS) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autogenerating headers bki stuff
On Sat, Jul 25, 2009 at 3:21 AM, Peter Eisentrautpete...@gmx.net wrote:
On Tuesday 30 June 2009 06:59:51 Robert Haas wrote:
The attached patch merges all of the logic currently in genbki.sh and
Gen_fmgrtab.{sh,pl} into a single script called gen_catalog.pl. It
then extends that logic to generate all of the Anum_* and Natts_*
constants, as well as the Schema_pg_* declarations for the bootstrap
tables.
I see a potential problem with the introduction of the catalog/anum.h header,
to hold the Anum_... defines. This looks like it could be a significant break
in the backend API, as evidenced by the fact that plperl and dblink no longer
compile with this change.
I think a less invasive change would be to include anum.h into all the
catalog/pg_*.h headers, so that the external interface stays the same.
Gah. I wish a toplevel make would build contrib.
Anyway, yeah, we could do that. The downsides to that approach are:
1. Changing a catalog definition in a way that actually affects the
contents of anum.h will force more things to be recompiled (note that
there are guards against useless rebuilds of anum.h), and
2. If we do that, we'll probably be stuck with it forever, and it
seems like a bit of a hack.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
This would seem to imply that all user defined trusted code has to
perform its own permission checks. How is MAC any different from DAC in
the presence of code such as:
CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD
LANGUAGE 'sql'
SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0'
AS 'SELECT * FROM customer';
In this case, confined users cannot create a function labeled as
'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is
controlled by db_procedure:{create} permission.
Yes, that seems reasonable. The fact that you're still talking about
confined users is slightly worrying and would seem to imply that
there is still a superuser/normal user divide--it's probably just a
terminology thing though.
One thing I know I don't understand is what the security labels actually
mean; I've had a couple of searches through your pages now and can't see
anything described nor pointers to external documentation.
Confined user can create a function with user_sepgsql_proc_exec_t
(which is the default one for confined users), but it is not a trusted
procedure, so the SELECT * FROM customer is executed with confined
user's privileges as is, then it will be failed due to the lack of
permission on the customer.credit.
So an unconfined user (whatever that means??) is basically working
with DACs then?
--
Sam http://samason.me.uk/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
Sam Mason wrote:
On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
This would seem to imply that all user defined trusted code has to
perform its own permission checks. How is MAC any different from DAC in
the presence of code such as:
CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD
LANGUAGE 'sql'
SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0'
AS 'SELECT * FROM customer';
In this case, confined users cannot create a function labeled as
'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is
controlled by db_procedure:{create} permission.
Yes, that seems reasonable. The fact that you're still talking about
confined users is slightly worrying and would seem to imply that
there is still a superuser/normal user divide--it's probably just a
terminology thing though.
One thing I know I don't understand is what the security labels actually
mean; I've had a couple of searches through your pages now and can't see
anything described nor pointers to external documentation.
I assume the wikipage (SEPostgreSQL_Draft) is a draft for the PostgreSQL
official documentation. However, the list of security labels originates
from the default security policy in SELinux.
So, I think an external link will be preferable for the references.
TODO: I'll make the list of security labels we can assign on.
Confined user can create a function with user_sepgsql_proc_exec_t
(which is the default one for confined users), but it is not a trusted
procedure, so the SELECT * FROM customer is executed with confined
user's privileges as is, then it will be failed due to the lack of
permission on the customer.credit.
So an unconfined user (whatever that means??) is basically working
with DACs then?
Sorry for using the undefined terminology.
The default security policy provides several security contexts that we
can assign on user's shell process, such as user_t, staff_t and unconfined_t.
(Please note that the security context of processes means its privileges.)
SELinux checks privileges of processes without any exceptions.
However, the default security policy allows anything on unconfined_t label.
It means unconfined users are allowed anything according to the policy.
(BTW, we can unplug the unconfined label using modular policy stuff.)
On the other hand, rest of security context (user_t, staff_t or httpd_t for
web servers) are confined, because the security policy does not allow
such widespread permissions.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Shouldn't psql -1 imply ON_ERROR_STOP?
When you run a file with psql -1/--single-transaction, and a command fails, you get bombarded with ERROR: current transaction is aborted, commands ignored until end of transaction block for the rest of the file. Shouldn't -1 imply ON_ERROR_STOP or some variant by default? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't psql -1 imply ON_ERROR_STOP?
On Saturday, July 25, 2009, Peter Eisentraut pete...@gmx.net wrote: When you run a file with psql -1/--single-transaction, and a command fails, you get bombarded with ERROR: current transaction is aborted, commands ignored until end of transaction block for the rest of the file. That would certainly be useful. Personally I'd prefer it to default to that always, and not just in -1, but that would break way too many old things I'm afraid... /Magnus Shouldn't -1 imply ON_ERROR_STOP or some variant by default? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't psql -1 imply ON_ERROR_STOP?
On Sat, Jul 25, 2009 at 9:06 AM, Magnus Hagandermag...@hagander.net wrote: On Saturday, July 25, 2009, Peter Eisentraut pete...@gmx.net wrote: When you run a file with psql -1/--single-transaction, and a command fails, you get bombarded with ERROR: current transaction is aborted, commands ignored until end of transaction block for the rest of the file. That would certainly be useful. Personally I'd prefer it to default to that always, and not just in -1, but that would break way too many old things I'm afraid... Doing it always would be really annoying. I often reload dumps that fail the grant statements but otherwise work. Admittedly, if I planned ahead, I could avoid having the grants be present in the dumps, but that would require planning ahead... But +1 for doing it when -1 is used. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: support empty string as separator for string_to_array
On Fri, Jul 24, 2009 at 11:40 PM, Pavel Stehulepavel.steh...@gmail.com wrote:
Hello
I have one idea, that should simplify string to char array
transformation. The base is idea: between every char is empty string,
so empty string is regular separator for string_to_array function.
This behave is inversion of array_to_string function behave:
postgres=# select array_to_string(array['a','b','c'],'');
array_to_string
-
abc
(1 row)
postgres=# select string_to_array('abc','');
string_to_array
-
{a,b,c}
(1 row)
postgres=# select regexp_split_to_array('abc', '');
regexp_split_to_array
---
{a,b,c}
(1 row)
:-)
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: support empty string as separator for string_to_array
2009/7/25 Merlin Moncure mmonc...@gmail.com:
On Fri, Jul 24, 2009 at 11:40 PM, Pavel Stehulepavel.steh...@gmail.com
wrote:
Hello
I have one idea, that should simplify string to char array
transformation. The base is idea: between every char is empty string,
so empty string is regular separator for string_to_array function.
This behave is inversion of array_to_string function behave:
postgres=# select array_to_string(array['a','b','c'],'');
array_to_string
-
abc
(1 row)
postgres=# select string_to_array('abc','');
string_to_array
-
{a,b,c}
(1 row)
postgres=# select regexp_split_to_array('abc', '');
regexp_split_to_array
---
{a,b,c}
(1 row)
I know - but regexp is not necessary - simply function for string
decomposition should be faster and little bit more intuitive. Not
everybody understand reg exp.
Pavel
:-)
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autogenerating headers bki stuff
Robert Haas robertmh...@gmail.com writes: On Sat, Jul 25, 2009 at 3:21 AM, Peter Eisentrautpete...@gmx.net wrote: I think a less invasive change would be to include anum.h into all the catalog/pg_*.h headers, so that the external interface stays the same. Gah. I wish a toplevel make would build contrib. Anyway, yeah, we could do that. The downsides to that approach are: I didn't realize this change was intending to throw all the Anum_ constants into a single header file. I am strongly against that on namespace pollution grounds, quite aside from the massive #include restructuring it'd require. And then there's the fact that any change in such a file would force rebuild of just about the entire backend. I do not see any virtue in autogenerating the Anum_ constants anyway. Yeah, manually updating them is a bit of a pain, but it's only a tiny part of the work that's normally involved in changing a system catalog. In any case, practically all of the benefit involved could be gotten by just not having to mess with the numerical values of the individual constants. Which we could do by setting them up as enums instead of macros, along the lines of http://archives.postgresql.org/pgsql-committers/2008-05/msg00080.php regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
Sam Mason s...@samason.me.uk writes: Yes, that seems reasonable. The fact that you're still talking about confined users is slightly worrying and would seem to imply that there is still a superuser/normal user divide--it's probably just a terminology thing though. There had better still be superusers. Or do you want the correctness of your backups to depend on whether your SELinux policy is correct? The first time somebody loses critical data because SELinux suppressed it from their pg_dump output, they're going to be on the warpath. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Non-blocking communication between a frontend and a backend (pqcomm)
Robert Haas robertmh...@gmail.com writes: On Fri, Jul 24, 2009 at 7:21 PM, Tom Lanet...@sss.pgh.pa.us wrote: I think you should just submit this with the code that uses it, so we can evaluate whether the overall concept is a good one or not. This was split out from Synch Rep based on my suggestion to submit separately any parts that are separately committable, but that doesn't seem to be the case given your comments here. I guess the question is whether it's necessary and/or desirable to put in the effort to create a general-purpose facility, or whether we should be satisfied with the minimum level of infrastructure necessary to support Synch Rep and just incorporate it into that patch. General-purpose facility *for what*? It's impossible to evaluate the code without a definition of the purpose behind it. What I actually think should come first is a spec for the client protocol this is intended to support. It's not apparent to me at the moment why the backend should need non-blocking read at all. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
On Jul 25, 2009, at 11:06 AM, Tom Lane wrote: Sam Mason s...@samason.me.uk writes: Yes, that seems reasonable. The fact that you're still talking about confined users is slightly worrying and would seem to imply that there is still a superuser/normal user divide--it's probably just a terminology thing though. There had better still be superusers. Or do you want the correctness of your backups to depend on whether your SELinux policy is correct? The first time somebody loses critical data because SELinux suppressed it from their pg_dump output, they're going to be on the warpath. This behavior is no different than when taking/using an SE-enabled filesystem backup. And woe to the admin who doesn't test his backups- caveat emptor. Still, it would be nice if pg_dump warned or stopped if the backup it created was completely useless (missing data dependencies), no? Cheers, M -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] When is a record NULL?
David E. Wheeler da...@kineticode.com wrote: So when it gets to that second row in the first cursor, it doesn't know it's a row with NULLs as opposed to an empty row. there ought to be an easy way to tell the difference. :-( I would have thought that the correct thing is to check SQLSTATE for '02000'. I can't see how PostgreSQL allows this, however. :-( -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] When is a record NULL?
On Fri, 2009-07-24 at 15:47 -0700, David E. Wheeler wrote: WHILE (NOT rec_have IS NULL AND rec_have IS DISTINCT FROM NULL) OR (NOT rec_want IS NULL AND rec_want IS DISTINCT FROM NULL) I don't think you want the NOT x IS NULL part at all -- that will evaluate to false when x = rec(NULL,NULL). I think you just want the x IS DISTINCT FROM NULL part, right? Will that work? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] When is a record NULL?
Sam Mason s...@samason.me.uk wrote: On Fri, Jul 24, 2009 at 12:30:39PM -0500, Kevin Grittner wrote: In this dichotomy a NULL is most definitely a value and with my current experience I don't understand the distinction you're trying to draw. There can be a place where a value *could* go which does not contain a value. Codd considered it crucial, from a mathematical correctness point of view, that the absence of a value not be indicated by some special magic value, but rather by some other technique which indicates that there *is* no value there. In SQL this is done with NULL. Based on reading his books, it seems to me that Codd always seemed uncomfortable with this, since it made it appear to be some special value, which he was adamant that it is *not*. It seems he would have preferred a relational language use a term like FLAGGED AS MISSING rather than IS NULL. It also would have allowed the flexibility to differentiate various types of missing values, such as FLAGGED AS UNKNOWN or FLAGGED AS NOT APPLICABLE. The distinction between not having a tuple and having a tuple for which you don't know any applicable values seems thin. I'm not sure what that would really mean. Other languages/type systems do define this precisely. Yeah, I've made my living programming for decades, and worked in dozens of languages, so I know how this is usually done. I do think that set logic in relational data involves some slightly different twists on things than most language have. I tend, for bettor or worse, to come down in agreement with the positions Codd espoused on most of these things. [PG] ... internally knows there is a distinction between the two but it doesn't like to expose this. Well, to some extent I think it's a tough problem, since the set logic of a relational database is implemented in C, which doesn't have the same concepts. There's got to be a little slight of hand in there somewhere. If your model is correct then when the IS DISTINCT FROM operator works on RECORDs the following should return FALSE for all of the following: SELECT NULL IS DISTINCT FROM ROW(NULL); SELECT NULL IS DISTINCT FROM ROW(NULL,NULL); SELECT NULL IS DISTINCT FROM ROW(NULL,ROW(NULL,NULL)); SELECT ROW(NULL) IS DISTINCT FROM ROW(NULL,ROW(NULL,NULL)); i.e. there is *no* difference between a NULL record and a record consisting entirely of NULLs. Well, on that I would go with whatever the SQL standard says, and hope it's not too ambiguous. (I haven't tried to sort though this one in the standard, so far.) I was going into the theory both because it is the basis for some of the seemingly odd aspects of SQL, and because at least half the time I see someone put the word NULL immediately in front of the word VALUE, they are wandering into confusion on these issues. (I will admit that using such technically incorrect language is sometimes hard to avoid without sounding stilted, even if all parties to the conversation know that NULL is *not* a value.) I know that Codd was insistent that any relation (which included the result of any query) which could contain duplicate rows should be called a corrupted relation. (In fact, in one of his books I think he averaged a comment on this point about once every two pages.) So I shudder to think what his reaction would be to a relation with a row which contained no values. I have a really hard time figuring out what useful information such a row could represent. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't psql -1 imply ON_ERROR_STOP?
Am 25.07.2009 um 15:00 schrieb Peter Eisentraut: When you run a file with psql -1/--single-transaction, and a command fails, you get bombarded with ERROR: current transaction is aborted, commands ignored until end of transaction block for the rest of the file. Shouldn't -1 imply ON_ERROR_STOP or some variant by default? Sounds reasonable, +1 from me. Regards Michael Paesold -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: support empty string as separator for string_to_array
Pavel Stehule pavel.steh...@gmail.com writes: I have one idea, that should simplify string to char array transformation. The base is idea: between every char is empty string, so empty string is regular separator for string_to_array function. There already is a definition for what string_to_array does with an empty field separator, and that is not it. So this change would possibly break existing applications. It does not seem either intuitively correct or useful enough to justify that --- particularly seeing that there's already another way to get the effect. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on
m...@postgresql.org (Magnus Hagander) writes: Log Message: --- Reserve the shared memory region during backend startup on Windows, so that memory allocated by starting third party DLLs doesn't end up conflicting with it. I am wondering why failure of the various TerminateProcess calls in postmaster.c is elog(ERROR) and not elog(LOG). While that probably shouldn't happen, aborting the postmaster isn't a good response if it does. This patch introduces a new occurrence, but I see it is just copying what was there already. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: support empty string as separator for string_to_array
2009/7/25 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: I have one idea, that should simplify string to char array transformation. The base is idea: between every char is empty string, so empty string is regular separator for string_to_array function. There already is a definition for what string_to_array does with an empty field separator, and that is not it. So this change would possibly break existing applications. It does not seem either intuitively correct or useful enough to justify that --- particularly seeing that there's already another way to get the effect. I thing, so nobody use empty separator in string_to_array, because it does nothing useful. Or do you know any case where empty separator should be used? I am not. My argument for some non regexp based function is fact, so this function should be very light and fast. Faster than regexp. Other way is one param string_to_array function. This function is not defined yet, so we could to use it. Regards Pavel regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: support empty string as separator for string_to_array
Pavel Stehule pavel.steh...@gmail.com writes: 2009/7/25 Tom Lane t...@sss.pgh.pa.us: There already is a definition for what string_to_array does with an empty field separator, and that is not it. I thing, so nobody use empty separator in string_to_array, because it does nothing useful. According to you, maybe not. But perhaps whoever coded the function originally had a use-case in mind, or people may have come up with one since then. In any case we have a perfectly good answer available for anyone who wants this behavior. I see no reason to change here. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mixed, named notation support
Hello,
fixed patch attached + more regress tests.
Regards
Pavel Stehule
2009/7/23 Pavel Stehule pavel.steh...@gmail.com:
2009/7/23 Bernd Helmle maili...@oopsware.de:
--On Donnerstag, März 05, 2009 08:41:28 +0100 Pavel Stehule
pavel.steh...@gmail.com wrote:
Hello
I did some cleaning on this feature, and I hope so I solve some Tom's
objections
features:
* PostgreSQL's specific syntax for named parameter: value AS name,
* Doesn't change rules for defaults,
* Get defaults for named, mixed notation in planner time.
Pavel, consider the following function:
CREATE OR REPLACE FUNCTION ftest(a int, b text)
RETURNS RECORD
LANGUAGE SQL
AS
$$
SELECT $1, $2 ;
$$;
#= SELECT ftest('blubb' AS b, 128 AS a);
ERROR: function ftest(unknown, integer) does not exist at character 8
#= SELECT ftest(128 AS a, 'abcd' AS b);
ftest
(128,abcd)
(1 row)
Isn't the first one supposed to work?
it is probably bug. I'll look on it tomorrow.
Pavel
--
Thanks
Bernd
named-fixed.diff.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Merge Append Patch merged up to 85devel
On Sun, Jul 5, 2009 at 7:23 PM, Greg Starkst...@mit.edu wrote: Here's a copy of the merge-append patch that I sent months ago merged up to head. I haven't really added any additional functionality since then. Can you provide some more details about the objective of this patch? Or a link to previous discussion? i was trying to test this one but i can't find a query that produces a diferent plan than in 8.4.0, attached my current test just in case... what kind of query is this intended to help? something, maybe style dependant, that i don't like is the definition of LAPPEND_PATH_FLATTEN_APPENDPATHS macro at some point in the middle of the file i prefer they be defined at the top (just my preference)... or there is a reason for doing it there? another thing a don't like is those #ifdef FIXME surrounding already existing if, why are those? and if they need to be fixed why there isn't a comment explaining what the fix is or what it should behave? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 drop database if exists mergeappend; create database mergeappend; \c mergeappend create table tab1 (col1 int); create table tab1_part1 (check (col1 between1 and 1000)) inherits (tab1); create table tab1_part2 (check (col1 between 1001 and 2000)) inherits (tab1); create table tab1_part3 (check (col1 between 2001 and 3000)) inherits (tab1); create table tab1_part4 (check (col1 between 3001 and 4000)) inherits (tab1); create table tab1_part5 (check (col1 between 4001 and 5000)) inherits (tab1); create table tab1_part6 (check (col1 between 5001 and 6000)) inherits (tab1); create table tab1_part7 (check (col1 between 6001 and 7000)) inherits (tab1); create table tab1_part8 (check (col1 between 7001 and 8000)) inherits (tab1); create table tab1_part9 (check (col1 between 8001 and 9000)) inherits (tab1); create table tab1_part10 (check (col1 between 9001 and )) inherits (tab1); insert into tab1_part1 select generate_series( 1, 1000); insert into tab1_part2 select generate_series(1001, 2000); insert into tab1_part3 select generate_series(2001, 3000); insert into tab1_part4 select generate_series(3001, 4000); insert into tab1_part5 select generate_series(4001, 5000); insert into tab1_part6 select generate_series(5001, 6000); insert into tab1_part7 select generate_series(6001, 7000); insert into tab1_part8 select generate_series(7001, 8000); insert into tab1_part9 select generate_series(8001, 9000); insert into tab1_part10 select generate_series(9001, ); create index idx1_tab1_part1 on tab1_part1(col1); create index idx1_tab1_part2 on tab1_part2(col1); create index idx1_tab1_part3 on tab1_part3(col1); create index idx1_tab1_part4 on tab1_part4(col1); create index idx1_tab1_part5 on tab1_part5(col1); create index idx1_tab1_part6 on tab1_part6(col1); create index idx1_tab1_part7 on tab1_part7(col1); create index idx1_tab1_part8 on tab1_part8(col1); create index idx1_tab1_part9 on tab1_part9(col1); create index idx1_tab1_part10 on tab1_part10(col1); analyze; set enable_sort to off; explain analyze select a.* from tab1 a, tab1 b where a.col1 = b.col1 -- and ((a.col1 = 997 and a.col1 = 1000) or --(a.col1 = 4999 and a.col1 = 5000) or --(a.col1 = 5995 and a.col1 = 6000)) order by a.col1 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] DefaultACLs
On Sat, Jul 25, 2009 at 11:14:19AM +0200, Petr Jelinek wrote: Joshua Tolley wrote: Am I the only one that gets this on make check, with this version (from src/test/regress/log/initdb.log): selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /home/josh/devel/pgsrc/pg85/src/test/regress/./tmp_check/data/base/1 ... FATAL: relation pg_namespace_default_acl already exists child process exited with exit code 1 initdb: data directory /home/josh/devel/pgsrc/pg85/src/test/regress/./tmp_check/data not removed at user's request Certainly never happened to me. Are you using any special parameters or something (altho I don't have the slightest idea what could cause that) ? I run make check on patches using gcc under debian and msvc on vista before sending them. I figured as much. I can't seem to get past this, despite a make distclean. Suggestions, anyone? -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [HACKERS] Merge Append Patch merged up to 85devel
On Sat, Jul 25, 2009 at 8:12 PM, Jaime Casanovajcasa...@systemguards.com.ec wrote: i was trying to test this one but i can't find a query that produces a diferent plan than in 8.4.0, attached my current test just in case... what kind of query is this intended to help? You may have to disable enable_seqscan to get simple examples like this to work: select * from partitioned_table order by indexed_column; more complex examples would trigger it naturally such as: select * from partitioned_table where active order by indexed_column (with an index on indexed_column where active) or select * from partitioned_table where indexed_column between x and y order by indexed_column something, maybe style dependant, that i don't like is the definition of LAPPEND_PATH_FLATTEN_APPENDPATHS macro at some point in the middle of the file i prefer they be defined at the top (just my preference)... or there is a reason for doing it there? well it's only used in that one function, it's just some code which is repeated three times and would obscure what's going on if it were inlined. another thing a don't like is those #ifdef FIXME surrounding already existing if, why are those? and if they need to be fixed why there isn't a comment explaining what the fix is or what it should behave? Yeah, if I knew how to fix them then this patch wouldn't be stuck waiting for feedback... :( -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] DefaultACLs
Joshua Tolley wrote: I figured as much. I can't seem to get past this, despite a make distclean. Suggestions, anyone? try a fresh checkout and reapply the patch? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Merge Append Patch merged up to 85devel
On Sat, Jul 25, 2009 at 2:26 PM, Greg Starkst...@mit.edu wrote: more complex examples would trigger it naturally such as: select * from partitioned_table where active order by indexed_column (with an index on indexed_column where active) or select * from partitioned_table where indexed_column between x and y order by indexed_column look at the example, i had three OR'ed conditions on col1 wich is indexed (in the script those where commented but i tried it first) and i get the same plan than in 8.4 but you're right with enable_seqscan to off i get a better plan, attaching explain analyze in 8.4 and 8.5 (with seqscan to on and off) another thing a don't like is those #ifdef FIXME surrounding already existing if, why are those? and if they need to be fixed why there isn't a comment explaining what the fix is or what it should behave? Yeah, if I knew how to fix them then this patch wouldn't be stuck waiting for feedback... :( and what's the problem with those if? as someone says before feel free to speak slowly and draw pictures ;) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 explain_analyze_84.out.gz Description: GNU Zip compressed data explain_analyze_85dev_seqscan_off.out.gz Description: GNU Zip compressed data explain_analyze_85dev_seqscan_on.out.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote: Sorry for using the undefined terminology. I think this is the largest missing part of the docs at the moment; there is a whole new world of definitions that need to be understood before the SE-PG stuff is understandable/usable by anyone and none of it is explained in a way I can understand. External links are fine at the moment (I think) but descriptions will need to exist. For example you currently define a security context as a formatted short string---how does that tell me why I would want one or what it does! As an example, PG currently has the following to describe what a role is: http://www.postgresql.org/docs/current/static/database-roles.html I'd expect a similar definition for each of the major terms in SE-PG; at the moment these seem to be security label, security context, security policy and others? What do others think? Hope that helps explain my confusion! If you point me at some docs I'll be happy to write/edit things to make them more relevant to PG. -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autogenerating headers bki stuff
On Sat, Jul 25, 2009 at 10:56 AM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sat, Jul 25, 2009 at 3:21 AM, Peter Eisentrautpete...@gmx.net wrote: I think a less invasive change would be to include anum.h into all the catalog/pg_*.h headers, so that the external interface stays the same. Gah. I wish a toplevel make would build contrib. Anyway, yeah, we could do that. The downsides to that approach are: I didn't realize this change was intending to throw all the Anum_ constants into a single header file. I am strongly against that on namespace pollution grounds, I don't really understand this objection. The reason why namespace pollution is bad is because there's a risk that someone might be using one of the names used for some other purpose, but the chances that someone who is using a Anum_pg_* or Natts_pg_* constant also needs a similarly named constant for some purpose other than referencing the PostgreSQL catalogs seems so as nearly zero as makes no difference. The hypothetical scenario in which this is a problem goes something like this: someone is counting on the fact that if they include catalog/pg_foo.h, then Anum_pg_foo_* and Natts_pg_foo will be defined appropriately for reference to PostgreSQL backend catalogs, but they are also counting on the fact that Anum_pg_bar_* and Natts_pg_bar (for some value of bar that collides with a system catalog name) are not defined and that they can use those constants for their own internal purposes. When they port their code to PG 8.5, they are forced into changing the naming of those constants, because it's no longer possible to just get the pg_foo constants without the pg_bar constants. If anyone is really doing this, I submit that it's a horribly bad idea and they ought to stop right away whether this patch gets committed or not. quite aside from the massive #include restructuring it'd require. This is all done in the patch (with the exception of a handful of loose ends that Peter found in his review) and I don't think it's all that massive. And then there's the fact that any change in such a file would force rebuild of just about the entire backend. It requires a rebuild of 56 of 547 files '*.c' files in src/backend, which is to say 10.2% of the backend. Also, the system is set up in such a way that the timestamp on catalog/anum.h changes only when its contents actually change, and dependencies are not rebuilt otherwise. So basically it'll happen when someone adds an attribute to, or removes one from, a system catalog: the fact that the .h file was updated in some other way is not sufficient. I do not see any virtue in autogenerating the Anum_ constants anyway. Yeah, manually updating them is a bit of a pain, but it's only a tiny part of the work that's normally involved in changing a system catalog. Well, I'd like to work on fixing some of the other problems too, but this seems like a good place to start. Currently, if there are two uncommitted patches that make changes to the system catalog, whichever is committed first is 100% guaranteed to conflict with each other, and the resolution is typically painful. Of course, fixing the Anum and Natts declarations does not come close to fixing this problem: for catalogs that are initialized with any data at bootstrap time, the DATA() lines are a much bigger issue, but fixing that is going to require a bigger hammer than can be put in place with one patch. I do think this is a pretty good foundation on which to build, though. In any case, practically all of the benefit involved could be gotten by just not having to mess with the numerical values of the individual constants. Which we could do by setting them up as enums instead of macros, along the lines of http://archives.postgresql.org/pgsql-committers/2008-05/msg00080.php I'd certainly be willing to concede that some of the benefit could be gotten that way, but I'm not sure I agree with practically all. The benefits of this patch as I see them are: (1) to reduce the number of places where a catalog change creates a merge conflict, and (2) to eliminate the possibility of human error in setting up the Anum and Natts declarations. The fact that I found a case where this had been done inconsistently in pg_listener (and no one noticed for 10 years) provides that this is not an entirely hypothetical possibility even for committed code, and I've definitely screwed it up a few times in my own tree, too. Replacing the declarations with enums would make the merge conflicts involve fewer lines and maybe slightly simplify the manual updating process, but it won't completely solve either problem. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote: There had better still be superusers. Or do you want the correctness of your backups to depend on whether your SELinux policy is correct? I thought the whole point of MAC was that superusers don't exist any more--at least not with the power they currently do. Organizations may well not trust specific parts of their database to certain types of backups, SE-PG should allow this to be controlled somewhat. The first time somebody loses critical data because SELinux suppressed it from their pg_dump output, they're going to be on the warpath. That should be solved by different methods; as A.M said pg_dump can complain if it doesn't see everything it expected to (which should handle the naive user case) and backdoors can be put in the scheme that will (by default?) initially allow a backup subject unfettered read-only access to each object. I'm expecting that this access can be revoked as needed from sensitive tables. -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote: On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote: There had better still be superusers. Or do you want the correctness of your backups to depend on whether your SELinux policy is correct? I thought the whole point of MAC was that superusers don't exist any more--at least not with the power they currently do. It's been billed that way, but it's not really accurate. A more accurate statement would be that it's possible to create a system in which there is no unconfined role. Organizations may well not trust specific parts of their database to certain types of backups, SE-PG should allow this to be controlled somewhat. I imagine it would be possible to run pg_dump on a database where you couldn't see all of the objects, and get a dump of just those, but that's only tangentially related to whether such things as superusers exist. If superusers DON'T exist, that would be making the opposite statement, namely, that there isn't ANY WAY to get a backup that you can be sure DOES contain all of the objects. And while I believe SE-Linux/SE-PostgreSQL would allow you to configure such a system, you might want to think carefully before you decide to do so, and the system certainly shouldn't (and can't) force you to set it up that way. The first time somebody loses critical data because SELinux suppressed it from their pg_dump output, they're going to be on the warpath. That should be solved by different methods; as A.M said pg_dump can complain if it doesn't see everything it expected to (which should handle the naive user case) and backdoors can be put in the scheme that will (by default?) initially allow a backup subject unfettered read-only access to each object. I'm expecting that this access can be revoked as needed from sensitive tables. If pg_dump can tell that there is information missing, the system hasn't done a very good job of hiding its existence, which is surely the whole point here. Even if SE-PostgreSQL isn't explicitly worried about eliminating covert channels, it seems like a terrible idea to design a database backup tool that operates by exploiting ones we haven't chosen to eliminate. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't psql -1 imply ON_ERROR_STOP?
--On Samstag, Juli 25, 2009 16:00:18 +0300 Peter Eisentraut pete...@gmx.net wrote: When you run a file with psql -1/--single-transaction, and a command fails, you get bombarded with ERROR: current transaction is aborted, commands ignored until end of transaction block for the rest of the file. Shouldn't -1 imply ON_ERROR_STOP or some variant by default? Only if it could ensured that embedded SAVEPOINTS can be handled properly...a quick check shows that ON_ERROR_STOP will stop any script even when the errorneous command is probably rolled back by a subsequent ROLLBACK TO: SELECT 1; SAVEPOINT A; SELECT et; -- ON_ERROR_STOP stops here ROLLBACK TO A; SELECT 2; It seems -1 needs some smarter variant of ON_ERROR_STOP. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehulepavel.steh...@gmail.com wrote: 2009/4/18 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: 2009/4/11 Tom Lane t...@sss.pgh.pa.us: No, I was complaining that a hook right there is useless and expensive. transformExpr() is executed multiple times per query, potentially a very large number of times per query; so even testing to see if a hook exists is not a negligible cost. I did some tests based on pgbench. The queries done by pgbench are completely trivial and do not stress parser performance. Even if they did (consider cases likw an IN with a few thousand list items), the parser is normally not a bottleneck compared to transaction overhead, network round trips, and pgbench itself. I though about different position of hook, but only in this place the hook is useful (because expressions are recursive). As I keep saying, a hook there is useless, at least by itself. You have no control over the grammar and no ability to modify what the rest of the system understands. The only application I can think of is to fool with the transformation of FuncCall nodes, which you could do in a much lower-overhead way by hooking into transformFuncCall. Even that seems pretty darn marginal for real-world problems. I am sending modified patch - it hooking parser via transformFuncCall I am reviewing this patch. It seems to me upon rereading the thread that the objections Tom and Peter had to inserting a hook into transformExpr() mostly still apply to a hook in transformFuncCall(): namely, that there's no proof that putting a hook here is actually useful. I think we should apply the same criteria to this that we have to some other patches that have been rejected (like the extensible-rmgr patch Simon submitted for CommitFest 2008-11), namely, requiring that the extension mechanism be submitted together with at least two examples of how it can be used to interesting and useful things, bundled as one or more contrib modules. There is some discussion on this thread of things that you think that this patch can be used to do, but I think it would be much easier to see whether it's (a) possible and (b) not too ugly to do those things if you reduce them to code. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG dynamic cursor, SQLDA support
On Wed, Jun 24, 2009 at 4:51 AM, Boszormenyi Zoltanz...@cybertec.at wrote: Hi, attached is our latest patch extending ECPG: haven't tested this nor reviewed the code in detail, just some little questions: 1) This is in /src/interfaces/ecpg/ecpglib/sqlda.c, and doesn't seems something we want in our files... looking at actual code seems like ecpg.c have something similar but at least specify that it has the same license as PostgreSQL + * + * (C) 2009 Cybertec GmbH + * Zoltán Böszörményi z...@cybertec.at + * Hans-Jürgen Schönig h...@cybertec.at + */ 2) In src/interfaces/ecpg/include/sqltypes.h there some #if 0 added, why are those? seems like something that doesn't need to be added + #if 0 + #define SQLSET 19 + #define SQLMULTISET 20 + #define SQLLIST 21 + #define SQLROW 22 + #define SQLCOLLECTION 23 + #define SQLROWREF 24 + #endif -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autogenerating headers bki stuff
Robert Haas robertmh...@gmail.com writes: On Sat, Jul 25, 2009 at 10:56 AM, Tom Lanet...@sss.pgh.pa.us wrote: I didn't realize this change was intending to throw all the Anum_ constants into a single header file. I am strongly against that on namespace pollution grounds, I don't really understand this objection. It's for the same reasons we don't put all of include/catalog/ into one giant header file, or all of include/ for that matter. It's bad for modularity, it's bad for compilation time, it's bad for rebuild time if you're using --enable-depend. The reason why namespace pollution is bad is because there's a risk that someone might be using one of the names used for some other purpose, Uh, no, that's actually pretty much irrelevant for our purposes. As a general rule, any two PG header files should be non-conflicting since some .c file might need to include both. So we'd have to get rid of conflicts anyhow. That does not make compartmentalization useless. As a for-instance, exposing names that a given .c file doesn't really need opens the door to typos that the compiler won't catch for you (ie, accidentally using the wrong Anum_ constant, in this context). [ other straw-man argumentation snipped ] None of this impresses me at all. We should not throw a pile of unrelated declarations into one header just to simplify the life of an automatic script. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG dynamic cursor, SQLDA support
On Sat, Jul 25, 2009 at 4:38 PM, Jaime Casanovajcasa...@systemguards.com.ec wrote: On Wed, Jun 24, 2009 at 4:51 AM, Boszormenyi Zoltanz...@cybertec.at wrote: Hi, attached is our latest patch extending ECPG: haven't tested this nor reviewed the code in detail, just some little questions: 1) This is in /src/interfaces/ecpg/ecpglib/sqlda.c, and doesn't seems something we want in our files... looking at actual code seems like ecpg.c have something similar but at least specify that it has the same license as PostgreSQL + * + * (C) 2009 Cybertec GmbH + * Zoltán Böszörményi z...@cybertec.at + * Hans-Jürgen Schönig h...@cybertec.at + */ seems like Michael already comment this but i lose that thread before... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Non-blocking communication between a frontend and a backend (pqcomm)
On Sat, Jul 25, 2009 at 11:41 AM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 24, 2009 at 7:21 PM, Tom Lanet...@sss.pgh.pa.us wrote: I think you should just submit this with the code that uses it, so we can evaluate whether the overall concept is a good one or not. This was split out from Synch Rep based on my suggestion to submit separately any parts that are separately committable, but that doesn't seem to be the case given your comments here. I guess the question is whether it's necessary and/or desirable to put in the effort to create a general-purpose facility, or whether we should be satisfied with the minimum level of infrastructure necessary to support Synch Rep and just incorporate it into that patch. General-purpose facility *for what*? It's impossible to evaluate the code without a definition of the purpose behind it. What I actually think should come first is a spec for the client protocol this is intended to support. It's not apparent to me at the moment why the backend should need non-blocking read at all. [ reads the patch ] OK, I agree, I can't see what this is for either from the code that is here. I think I read a little more meaning into the title of the patch than was actually there. It seems like the appropriate thing to do is mark this returned with feedback, so I'm going to go do that. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] visibility maps and heap_prune
On Tue, Jul 21, 2009 at 2:37 AM, Pavan Deolaseepavan.deola...@gmail.com wrote: On Tue, Jul 21, 2009 at 10:38 AM, Robert Haasrobertmh...@gmail.com wrote: Pavan, are you planning to respond to Alex's comments and/or update this patch? Yes, I will. Hopefully by end of this week. Since it has now been 10 days since this patch was reviewed, I think that it is more than fair to move this from Waiting on Author to Returned with Feedback. As I've said on other threads, we want to give everyone a fair chance to respond to review comments, but we also don't want to tie up reviewers indefinitely on patches that aren't being updated in a timely fashion, and we don't want to be left with a crush of patches that need to be re-reviewed at the very end of the CommitFest when suddenly everyone updates them. So I'm going to go make this change. I hope, though, that this will be resubmitted, after appropriate updating, for a future CommitFest. I haven't read the code so I can't speak at all to whether it works (in which I'm including crash-safe, deadlock-proof, and correct with respect to locking), but if so it sounds like a nice improvement. Thanks, ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autogenerating headers bki stuff
On Sat, Jul 25, 2009 at 9:17 PM, Robert Haasrobertmh...@gmail.com wrote: Of course, fixing the Anum and Natts declarations does not come close to fixing this problem: for catalogs that are initialized with any data at bootstrap time, the DATA() lines are a much bigger issue, but fixing that is going to require a bigger hammer than can be put in place with one patch. I do think this is a pretty good foundation on which to build, though. I think addressing that would actually be fairly simple in theory. Move a lot of those DATA lines to SQL initdb scripts. Virtually all of pg_proc, pg_operator, pg_opclass, pg_opfamily, pg_cast, etc can be initialized using SQL. Hardly any of the records in there are needed for bootstrapping. That would reduce the pain of editing this files *enormously*. The worst part of adding new operators is making sure all the opclass entries line up properly. And when there's an OID conflict and they all have to be renumbered and the opclasses fixed up that's when they're a real headache. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Robert Haas robertmh...@gmail.com writes: I think we should apply the same criteria to this that we have to some other patches that have been rejected (like the extensible-rmgr patch Simon submitted for CommitFest 2008-11), namely, requiring that the extension mechanism be submitted together with at least two examples of how it can be used to interesting and useful things, bundled as one or more contrib modules. I wouldn't necessarily insist on actual contrib modules. But fully worked-out example uses would certainly go a long way toward proving that the hook is good for something. In previous cases we've sometimes found out that a proposed hook definition isn't quite right after we try to use it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autogenerating headers bki stuff
Greg Stark gsst...@mit.edu writes: Move a lot of those DATA lines to SQL initdb scripts. Virtually all of pg_proc, pg_operator, pg_opclass, pg_opfamily, pg_cast, etc can be initialized using SQL. Hardly any of the records in there are needed for bootstrapping. It's easy to make that claim, much less easy to actually do it. The other issue is that there will be some fraction of the entries that unavoidably *are* needed before you can use SQL to insert the rest. What will we do with those? Having two different representations for essentially the same kind of data isn't much fun. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autogenerating headers bki stuff
[ dept. of second thoughts ] I wrote: It's easy to make that claim, much less easy to actually do it. Reflecting on this a bit more ... it seems to me that it's not the right thing to set the goal as try to get rid of as many DATA statements as possible. The right way to think about this is to classify the stuff we have got in DATA statements, and consider how to reduce the pain associated with the harder-to-maintain categories. In particular, I think Greg correctly identified the main pain point as being the catalog entries associated with operator classes (ie, pg_opclass, pg_opfamily, pg_amop, pg_amproc entries). So what I'm thinking is we should consider how to migrate *all* of those entries into CREATE OPERATOR CLASS/FAMILY commands. And I think that that might be doable. Those entries are not needed by the system until we create catalog indexes. So maybe we could split the current bootstrap phase into three phases: * create core catalogs and load DATA commands, using bki * create operator classes, using sql script * create indexes, using bki * proceed on as before I'm not nearly as excited about migrating all or even most of, say, the pg_proc DATA lines into SQL. That simply isn't going to buy very much in maintainability --- a patch that wants to add a new property to all the functions is going to conflict just as much with another patch doing the same. And it is going to cost us in places like how do we generate the fmgr lookup table. Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] When is a record NULL?
On Jul 25, 2009, at 9:24 AM, Jeff Davis wrote: I don't think you want the NOT x IS NULL part at all -- that will evaluate to false when x = rec(NULL,NULL). I think you just want the x IS DISTINCT FROM NULL part, right? Will that work? Nope, infinite loop when because `ROW(null, null)` and `ROW()` are both distinct from null: try=# select row(null, null) is distinct from null, row() is distinct from null; ?column? | ?column? --+-- t| t (1 row) So I still can't tell when I've exhausted a cursor. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] When is a record NULL?
On Jul 25, 2009, at 9:42 AM, Kevin Grittner wrote:
I know that Codd was insistent that any relation (which included the
result of any query) which could contain duplicate rows should be
called a corrupted relation. (In fact, in one of his books I think
he averaged a comment on this point about once every two pages.) So I
shudder to think what his reaction would be to a relation with a row
which contained no values. I have a really hard time figuring out
what useful information such a row could represent.
I agree that it's pathological, but it's clearly allowed by SQL, so we
need to be able to deal with it effectively. Intuitively would be
nice, but effectively will do.
Consider:
CREATE TABLE peeps (
name TEXT NOT NULL,
dob date,
ssn text,
active boolean NOT NULL DEFAULT true
);
INSERT INTO peeps
VALUES ('Tom', '1963-03-23', '123-45-6789', true),
('Damian', NULL, NULL, true),
('Larry', NULL, '932-45-3456', true),
('Bruce', '1965-12-31', NULL, true);
% SELECT dob, ssn from peeps where active;
dob | ssn
+-
1963-03-23 | 123-45-6789
[null] | [null]
[null] | 932-45-3456
1965-12-31 | [null]
Useless perhaps, but it's gonna happen, and someone may even have a
reason for it. Until such time as NULLs are killed off, we need to be
able to deal with SQL's pathologies.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] DefaultACLs
On Sat, Jul 25, 2009 at 03:50:06PM -0400, Andrew Dunstan wrote: Joshua Tolley wrote: I figured as much. I can't seem to get past this, despite a make distclean. Suggestions, anyone? try a fresh checkout and reapply the patch? [ a couple git clean, git reset, make clean, etc. commands later... ] Yeah, well, it works now. What's more, the problems I had with make check the first time I tried this are no longer. I've done all the looking I can think to do at the patch in its existing form, and don't have any complaints. I realize, though, that there are open questions about how this should work with, given the GRANT ON ALL patch. I'm not sure I have comments in that regard, but I'll try to come up with some, or at least to convince myself I don't have any for a better reason than just that I wouldn't know what I was talking about. In the meantime, I think this one is ready to be marked as ... something else. Ready for committer? -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [HACKERS] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote: On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote: I thought the whole point of MAC was that superusers don't exist any more--at least not with the power they currently do. It's been billed that way, but it's not really accurate. A more accurate statement would be that it's possible to create a system in which there is no unconfined role. Yes, that sounds more precise! I'm still unsure of terminology; what's a unconfined role? I guess the layman's description is similar to a superuser, but I'm sure there's a more refined definition somewhere. Hum, I've just found Fedora's guide, is the following considered a reasonable picture: http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html Organizations may well not trust specific parts of their database to certain types of backups, SE-PG should allow this to be controlled somewhat. I imagine it would be possible to run pg_dump on a database where you couldn't see all of the objects, and get a dump of just those, but that's only tangentially related to whether such things as superusers exist. I'm not sure what point you're trying to make; in my understanding superusers can see and do anything--hence they can make a backup. If superusers DON'T exist, that would be making the opposite statement, namely, that there isn't ANY WAY to get a backup that you can be sure DOES contain all of the objects. The traditional approach would be to maintain multiple physically separate databases; in this setup it's obvious that when you perform a backup of one of these databases you're only seeing a subset of all of the objects. Isn't SE-PG just allowing you to do this within a single PG database? And while I believe SE-Linux/SE-PostgreSQL would allow you to configure such a system, you might want to think carefully before you decide to do so, and the system certainly shouldn't (and can't) force you to set it up that way. I agree that this would seem to make the resulting system easier to manage, however I can also imagine scenarios where the converse would be true. This is a fuzzy engineering decision of the sort that I don't like making without a use case---and it would be nice to have several here. pg_dump can complain if it doesn't see everything it expected to If pg_dump can tell that there is information missing, the system hasn't done a very good job of hiding its existence, which is surely the whole point here. Hum, good point--scratch that idea then! -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] DefaultACLs
On Sat, Jul 25, 2009 at 7:45 PM, Joshua Tolleyeggyk...@gmail.com wrote: that I wouldn't know what I was talking about. In the meantime, I think this one is ready to be marked as ... something else. Ready for committer? Sounds right to me. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] DefaultACLs
On Sun, Jul 19, 2009 at 06:13:32PM +0200, Petr Jelinek wrote: while writing some basic docs I found bug in dependency handling when doing SET on object type that already had some default privileges. Attached patch fixes it, it also fixes thinko in parser (DROPing GRANT OPTION behaves like REVOKE now). And there is also initial version of those basic docs included (but you have to pardon my english as I didn't pass it to Stephen for proofreading due to discovery of that bug). Immediately after concluding I was done with my review, I realized I'd completely forgotten to look at the docs. I've made a few changes based solely on my opinions of what sounds better and what's more consistent with the existing documentation. Do with them as you see fit. :) -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [HACKERS] When is a record NULL?
On Sat, Jul 25, 2009 at 11:42:04AM -0500, Kevin Grittner wrote: Sam Mason s...@samason.me.uk wrote: In this dichotomy a NULL is most definitely a value and with my current experience I don't understand the distinction you're trying to draw. There can be a place where a value *could* go which does not contain a value. Codd considered it crucial, from a mathematical correctness point of view, that the absence of a value not be indicated by some special magic value, but rather by some other technique which indicates that there *is* no value there. In SQL this is done with NULL. Based on reading his books, it seems to me that Codd always seemed uncomfortable with this, since it made it appear to be some special value, which he was adamant that it is *not*. Have you used more academic languages like ML or Haskell? Their option and Maybe types, respectively, provide the nicest practical treatment I've seen of this. It seems he would have preferred a relational language use a term like FLAGGED AS MISSING rather than IS NULL. It also would have allowed the flexibility to differentiate various types of missing values, such as FLAGGED AS UNKNOWN or FLAGGED AS NOT APPLICABLE. Those sorts of lists get domain specific *very* quickly. I think languages are better off providing a type system of enough complexity to express maybe types and letting users invent whatever is most useful for the job at hand. I do think that set logic in relational data involves some slightly different twists on things than most language have. You must live in a very different world from me then! :) I tend, for bettor or worse, to come down in agreement with the positions Codd espoused on most of these things. I've not read much of his writings, any canonical references for this sort of discussion? [PG] ... internally knows there is a distinction between the two but it doesn't like to expose this. Well, to some extent I think it's a tough problem, since the set logic of a relational database is implemented in C, which doesn't have the same concepts. There's got to be a little slight of hand in there somewhere. That's a pretty bad excuse; everything ends up as machine code in the end. Many languages expose very abstract and consistent views of things, some of them a lot more awkward than that of a relational database. PG is admittedly hampered by a desire to follow a particularly innovative standard and correctness for PG commonly means keeping data safe. Being logically consistent normally takes a minor role, although there is quite a lot of overlap between the two. If your model is correct then when the IS DISTINCT FROM operator works on RECORDs the following should return FALSE for all of the following: SELECT NULL IS DISTINCT FROM ROW(NULL); SELECT NULL IS DISTINCT FROM ROW(NULL,NULL); SELECT NULL IS DISTINCT FROM ROW(NULL,ROW(NULL,NULL)); SELECT ROW(NULL) IS DISTINCT FROM ROW(NULL,ROW(NULL,NULL)); i.e. there is *no* difference between a NULL record and a record consisting entirely of NULLs. Well, on that I would go with whatever the SQL standard says, and hope it's not too ambiguous. (I haven't tried to sort though this one in the standard, so far.) I've had a reasonable browse around an old copy of SQL'08 I found, but couldn't find much helpful. The definition of distinct (3.1.6.8 in my copy) seems particularly vacuous, it would seem to leave it down to how rows are constructed and I can't find many details of that. I was going into the theory both because it is the basis for some of the seemingly odd aspects of SQL, and because at least half the time I see someone put the word NULL immediately in front of the word VALUE, they are wandering into confusion on these issues. (I will admit that using such technically incorrect language is sometimes hard to avoid without sounding stilted, even if all parties to the conversation know that NULL is *not* a value.) I think that depends on what definition of value you're using. If you're considering it to be a value like a NULL pointer then I'd agree as this is just a convention to treat pointers with a value of zero specially. If you treat values as members of a set with the set defined as their type and a sub-type relation existing between types then a NULL value is the only member of an unnamed type (in SQL) that's the subtype of all other types. There are other ways of formalizing this, and I've probably explained it badly here, but it's a rough sketch of how I think about it. I know that Codd was insistent that any relation (which included the result of any query) which could contain duplicate rows should be called a corrupted relation. (In fact, in one of his books I think he averaged a comment on this point about once every two pages.) So I shudder to think what his reaction would be to a relation with a row which contained no values. I have a really
Re: [HACKERS] [PATCH] DefaultACLs
On Sat, Jul 25, 2009 at 8:39 PM, Joshua Tolleyeggyk...@gmail.com wrote: On Sun, Jul 19, 2009 at 06:13:32PM +0200, Petr Jelinek wrote: while writing some basic docs I found bug in dependency handling when doing SET on object type that already had some default privileges. Attached patch fixes it, it also fixes thinko in parser (DROPing GRANT OPTION behaves like REVOKE now). And there is also initial version of those basic docs included (but you have to pardon my english as I didn't pass it to Stephen for proofreading due to discovery of that bug). Immediately after concluding I was done with my review, I realized I'd completely forgotten to look at the docs. I've made a few changes based solely on my opinions of what sounds better and what's more consistent with the existing documentation. Do with them as you see fit. :) Did you intend to attach something to this email? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] DefaultACLs
On Sat, Jul 25, 2009 at 08:41:12PM -0400, Robert Haas wrote:
On Sat, Jul 25, 2009 at 8:39 PM, Joshua Tolleyeggyk...@gmail.com wrote:
On Sun, Jul 19, 2009 at 06:13:32PM +0200, Petr Jelinek wrote:
while writing some basic docs I found bug in dependency handling when
doing SET on object type that already had some default privileges.
Attached patch fixes it, it also fixes thinko in parser (DROPing GRANT
OPTION behaves like REVOKE now). And there is also initial version of
those basic docs included (but you have to pardon my english as I didn't
pass it to Stephen for proofreading due to discovery of that bug).
Immediately after concluding I was done with my review, I realized I'd
completely forgotten to look at the docs. I've made a few changes based
solely
on my opinions of what sounds better and what's more consistent with the
existing documentation. Do with them as you see fit. :)
Did you intend to attach something to this email?
...Robert
Well, yes, now that you mention it :) Trying again...
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 34679d8..3eb92a4 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -3130,6 +3130,70 @@
/sect1
+ sect1 id=catalog-pg-namespace-default-acl
+ titlestructnamepg_namespace_default_acl/structname/title
+
+ indexterm zone=catalog-pg-namespace-default-acl
+ primarypg_namespace_default_acl/primary
+ /indexterm
+
+ para
+ The catalog structnamepg_namespace_default_acl/ stores default
+ privileges for newly created objects inside the schema.
+ /para
+
+ table
+ titlestructnamepg_namespace/ Columns/title
+
+ tgroup cols=4
+thead
+ row
+ entryName/entry
+ entryType/entry
+ entryReferences/entry
+ entryDescription/entry
+ /row
+/thead
+
+tbody
+ row
+ entrystructfielddefaclnamespace/structfield/entry
+ entrytypeoid/type/entry
+ entryliterallink linkend=catalog-pg-namespacestructnamepg_namespace/structname/link.oid/literal/entry
+ entryThe OID of the namespace associated with this entry/entry
+ /row
+
+ row
+ entrystructfielddefaclgrantobjtype/structfield/entry
+ entrytypechar/type/entry
+ entry/entry
+ entry
+ literalr/ = table, literalv/ = view,
+ literalf/ = function, literalS/ = sequence
+ /entry
+ /row
+
+ row
+ entrystructfielddefacllist/structfield/entry
+ entrytypeaclitem[]/type/entry
+ entry/entry
+ entry
+ Access privileges that the object should have on creation.
+ This is NOT a mask, it's exactly what the object will get.
+ See
+ xref linkend=sql-alterschema endterm=sql-alterschema-title,
+ xref linkend=sql-grant endterm=sql-grant-title and
+ xref linkend=sql-revoke endterm=sql-revoke-title
+ for details.
+ /entry
+ /row
+/tbody
+ /tgroup
+ /table
+
+ /sect1
+
+
sect1 id=catalog-pg-opclass
titlestructnamepg_opclass/structname/title
diff --git a/doc/src/sgml/ref/alter_schema.sgml b/doc/src/sgml/ref/alter_schema.sgml
index 2458d19..62f4c2a 100644
--- a/doc/src/sgml/ref/alter_schema.sgml
+++ b/doc/src/sgml/ref/alter_schema.sgml
@@ -23,18 +23,46 @@ PostgreSQL documentation
synopsis
ALTER SCHEMA replaceablename/replaceable RENAME TO replaceablenewname/replaceable
ALTER SCHEMA replaceablename/replaceable OWNER TO replaceablenewowner/replaceable
+
+ALTER SCHEMA replaceablename/replaceable { SET | ADD } DEFAULT PRIVILEGES { { ON default_privileges
+ TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable | PUBLIC } [, ...] [ WITH GRANT OPTION ] } [AND ...] } [...]
+
+where replaceable class=PARAMETERdefault_privileges/replaceable is:
+
+{ { TABLE | VIEW } { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
+[,...] | ALL [ PRIVILEGES ] } |
+ SEQUENCE { { USAGE | SELECT | UPDATE }
+[,...] | ALL [ PRIVILEGES ] } |
+ FUNCTION { EXECUTE | ALL [ PRIVILEGES ] } }
+
+ALTER SCHEMA replaceablename/replaceable DROP DEFAULT PRIVILEGES { { ON drop_default_privileges
+ FROM { [ GROUP ] replaceable class=PARAMETERrolename/replaceable | PUBLIC } [, ...] } [AND ...] } [...]
+
+where replaceable class=PARAMETERdrop_default_privileges/replaceable is:
+
+{ { TABLE | VIEW } [ GRANT OPTION FOR ]
+ { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
+[,...] | ALL [ PRIVILEGES ] } |
+ SEQUENCE [ GRANT OPTION FOR ]
+ { { USAGE | SELECT | UPDATE } [,...] | ALL [ PRIVILEGES ] } |
+ FUNCTION [ GRANT OPTION FOR ]
+ { EXECUTE | ALL [ PRIVILEGES ] } }
/synopsis
/refsynopsisdiv
- refsect1
+ refsect1 id=sql-alterschema-description
titleDescription/title
para
- commandALTER SCHEMA/command changes the definition of a schema.
+ You must own the schema to use commandALTER SCHEMA/.
/para
+ /refsect1
+
+ refsect1
[HACKERS] CommitFest Status Summary - 2009-07-25
All, A few hours ago I assigned a reviewer to the last patch for this CommitFest which still lacked one, with the exception of Heikki's index-only quals patch, which I'm not sure can be reviewed at this point because it depends on the indexam API changes patch, which is still up in the air. One thing I have belatedly realized about this CommitFest is that we (or at least, I) did not think about asking the committers about their schedules, and it turns out that three of them - Heikki, Michael Meskes, Joe Conway - are away at the moment. About 25% of the remaining patches are waiting for one of those three people to take the next step (as either patch author, or reviewer, or committer). That's not exactly a catastrophe considering that we have informally decided that a CommitFest is about a month long, and we're only 10 days into it, but may mean that there's not much left for non-committers to do well before all of the patches are actually dealt with. I've attached below a summary of which patches are waiting on which people, to the best of my ability to determine such things. It's basically the same information that's on commitfest.postgresql.org, but broken up differently and annotated with notes here and there. There are a couple of patches that are ostensibly waiting on reviewer activity that may really be ready for committer; the others are reviews that aren't finished, and we may want to think about adding additional reviewers to help move things along. Also, there are a few patches that are waiting on author which are nearly done, and it may make sense for someone other than the patch author to pick them up and finish them so that we can move forward with them. Any thoughts/ideas/etc. welcome. ...Robert Specific Committers (13) - generic explain options v3 (needs further review by Tom Lane) - Indexam API changes (Heikki Linnakangas as patch author) - Index-only quals (Heikki Linnakangas as patch author) - Determine cient_encoding from client locale (Heikki Linnakangas as patch author) - plpythonu datatype conversion improvements (Peter Eisentraut as committer) - dependencies for generated header files (Peter Eisentraut as reviewer) - Fix memory leak in win32 security functions (Magnus Hagander as patch author and presumed committer) - ECPG dynamic cursor, SQLDA support (Michael Meskes as reviewer) - ECPG support for string pseudo-type v2 (Michael Meskes as reviewer) - async notifications for dblink (Joe Conway as reviewer) - query cancel issues in dblink (Joe Conway as reviewer) - has_sequence_privilege() function (Joe Conway as reviewer) - Polygons (Teodor Sigaev as committer) Unspecified Committer (4) - GRANT ON ALL IN schema - Provide support for multiplexing SIGUSR1 signal - Deferrable unique constraints - DefaultACLs Reviewer (10) - ALTER TABLE ... ALTER COLUMN ... SET DISTINCT - Revise parallel pg_restore's scheduling heuristic - Merge append - Support for in to_char() (may be ready for committer) - multi-threaded pgbench (may be ready for committer) - Improvements for dict_xsyn extended synonym dictionary - new bytea hex output format - return query and dropped columns (perhaps this should be marked ready for committer?) - Prefix support for synonym dictionary (just assigned) - Filtering dictionary support and unaccent dictionary (just assigned) Author (8) - Named and mixed notation for PL - \dL for languages - WIP: TODO Item 'Add prompt escape to display the client and server versions' - hstore enhancements - Lock wait statistics (Tom doesn't like it, may be doomed) - Parser's hook based on FuncCall (seems to need major expansion, may be too much for this CF) - autogenerating headers bki stuff (Tom doesn't like it, may be doomed) - better support for win64 via intptr_t (seems to need major reworking, may be too much for this CF) Limbo (2) - machine-readable explain output v2 (can't update this patch until issues with generic explain options v3 are resolved) - report key values in duplicate-key errors (not really sure whose court the ball is in at this point) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autogenerating headers bki stuff
On Sat, Jul 25, 2009 at 6:40 PM, Tom Lanet...@sss.pgh.pa.us wrote: I'm not nearly as excited about migrating all or even most of, say, the pg_proc DATA lines into SQL. That simply isn't going to buy very much in maintainability --- a patch that wants to add a new property to all the functions is going to conflict just as much with another patch doing the same. And it is going to cost us in places like how do we generate the fmgr lookup table. Thoughts? I think it would actually buy you quite a bit to migrate them to SQL, because in SQL, default properties can generally be omitted, which means that a patch which adds a new property to pg_proc that takes the same value for every row doesn't actually need to touch the SQL at all. I suspect that's a pretty common case, too: SE-PostgreSQL modifies a whole bunch of system catalogs to add a security label attribute, and ALTER TABLE ... ALTER COLUMN ... SET DISTINCT adds a column to pg_attribute that defaults to 0. I can hear you objecting that there's no possible way we can use SQL to construct pg_attribute, and that's certainly true. But I have another idea. What we could do is generate the BKI but using some more sophisticated method than just writing it all out longhand in the header files and copying it over into the bki file. The pg_attribute entries for the bootstrap tables, for example, are mostly inferrable from the PG_CATALOG() declarations (I think storage class and maybe one other property might be problematic). And certainly you could design a more human readable format for the pg_proc entries, maybe something like: DATA_PG_PROC(function-name, function-arg1-type-name function-arg2-type-name, function-return-type-name,language,definition) To convert this into BKI, you make an initial pass through pg_type.h and collect the OIDs of all the type names. Then you zip through pg_proc.h and now you have enough information to map all the type names into OIDs and generate the BKI. I'm waving my hands a little bit here but I really don't think this is too hard, coding-wise, and it seems like it would make it a LOT easier to edit this file... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] improvements for dict_xsyn extended synonym dictionary - RRR
Hi Sergey, On Tuesday 14 July 2009 21:35:28 Sergey V. Karpov wrote: attached is a simple patch that extends the functionality of dict_xsyn extended synonym dictionary (from contrib) by adding the following configuration option: - mode option controls the current dictionary mode of operation. Can be one of: - in simple mode it accepts the original word and returns all synonyms as ORed lis. - when mode is symmetric, the dictionary accepts the original word or any of its synonyms, and return all others as ORed list. - in map regime it accepts any synonym and returns the original word instead of it. Also, it accepts and returns the original word itself, even if keeporig is false. Some points: - Patch looks generally sound - lacks a bit of a motivational statement, even though one can imagine uses - Imho mode=MAP should error out if keeporig is false - I personally find the the names for the different modes a bit nondescriptive. One possibility would be to introduce parameters like: - matchorig - matchsynonym - keeporig - keepsynonym That sounds way much easier to grasp for me. Comments? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
Sam Mason wrote: On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote: Sorry for using the undefined terminology. I think this is the largest missing part of the docs at the moment; there is a whole new world of definitions that need to be understood before the SE-PG stuff is understandable/usable by anyone and none of it is explained in a way I can understand. External links are fine at the moment (I think) but descriptions will need to exist. For example you currently define a security context as a formatted short string---how does that tell me why I would want one or what it does! As an example, PG currently has the following to describe what a role is: http://www.postgresql.org/docs/current/static/database-roles.html Indeed, the draft used the term of security context with minimum introductions, but not enough friendliness for database folks. The purpose of security context is an identifier of any subject and object to describe them in the security policy. Because the security policy is common for operating system, databases, x-window and others, any managed database objects needs its security context. Anyway, I need to introduce them in the security model section. I'd expect a similar definition for each of the major terms in SE-PG; at the moment these seem to be security label, security context, security policy and others? What do others think? The security label is an identical one with security context. Due to the historical reason, I uses a term of SECURITY_LABEL for interfaces, but it might be more easy understandable to use SECURITY_CONTEXT instead. For the security policy, I introduce it at the security model section: | Access control is conceptually to decide a set of allowed (or denied) | actions between a certain subject (such as a database client) and an | object (such as a table), and to apply the decision on user's requests. | At the database privilege system, ACL stored in database objects itself | holds a list of allowed actions to certain database roles, and it is | applied on the user's request. | SELinux also holds massive sets of allowed actions between a certain | subject and a certain object, we call them security policy. Is it obscure? In addition, I also think it needs to define some other terms explicitly. For example, what the term of labeled means. Hope that helps explain my confusion! If you point me at some docs I'll be happy to write/edit things to make them more relevant to PG. At this point, the SELinux user's guide in Fedora is the most comprehensive documentation. It is described from the viewpoint of SELinux users, not experts or developers. http://docs.fedoraproject.org/selinux-user-guide/ Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Koheikai...@kaigai.gr.jp wrote: | Access control is conceptually to decide a set of allowed (or denied) | actions between a certain subject (such as a database client) and an | object (such as a table), and to apply the decision on user's requests. | At the database privilege system, ACL stored in database objects itself | holds a list of allowed actions to certain database roles, and it is | applied on the user's request. | SELinux also holds massive sets of allowed actions between a certain | subject and a certain object, we call them security policy. Is it obscure? It's obscure to me. :-) I think you need to define security policy more precisely and give at least one or two examples of security policy entries. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Hello 2009/7/25 Robert Haas robertmh...@gmail.com: On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehulepavel.steh...@gmail.com wrote: 2009/4/18 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: 2009/4/11 Tom Lane t...@sss.pgh.pa.us: No, I was complaining that a hook right there is useless and expensive. transformExpr() is executed multiple times per query, potentially a very large number of times per query; so even testing to see if a hook exists is not a negligible cost. I did some tests based on pgbench. The queries done by pgbench are completely trivial and do not stress parser performance. Even if they did (consider cases likw an IN with a few thousand list items), the parser is normally not a bottleneck compared to transaction overhead, network round trips, and pgbench itself. I though about different position of hook, but only in this place the hook is useful (because expressions are recursive). As I keep saying, a hook there is useless, at least by itself. You have no control over the grammar and no ability to modify what the rest of the system understands. The only application I can think of is to fool with the transformation of FuncCall nodes, which you could do in a much lower-overhead way by hooking into transformFuncCall. Even that seems pretty darn marginal for real-world problems. I am sending modified patch - it hooking parser via transformFuncCall I am reviewing this patch. It seems to me upon rereading the thread that the objections Tom and Peter had to inserting a hook into transformExpr() mostly still apply to a hook in transformFuncCall(): namely, that there's no proof that putting a hook here is actually useful. I think we should apply the same criteria to this that we have to some other patches that have been rejected (like the extensible-rmgr patch Simon submitted for CommitFest 2008-11), namely, requiring that the extension mechanism be submitted together with at least two examples of how it can be used to interesting and useful things, bundled as one or more contrib modules. I have in my plan add to contrib JSON support similar to Bauman design: http://www.mysqludf.org/lib_mysqludf_json/index.php It's will be sample of smart functions. Because this need more then less work I am waiting on commit. Other simple intrduction contrib module should be real Oracle decode function - I sent source code some time ago. But this code needs some modification. I should send this code if you need it. Pavel There is some discussion on this thread of things that you think that this patch can be used to do, but I think it would be much easier to see whether it's (a) possible and (b) not too ugly to do those things if you reduce them to code. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
Robert Haas wrote: On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Koheikai...@kaigai.gr.jp wrote: | Access control is conceptually to decide a set of allowed (or denied) | actions between a certain subject (such as a database client) and an | object (such as a table), and to apply the decision on user's requests. | At the database privilege system, ACL stored in database objects itself | holds a list of allowed actions to certain database roles, and it is | applied on the user's request. | SELinux also holds massive sets of allowed actions between a certain | subject and a certain object, we call them security policy. Is it obscure? It's obscure to me. :-) I think you need to define security policy more precisely and give at least one or two examples of security policy entries. OK, I'll try to define it more precisely and introduce a few examples in the documents. Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
On Sat, Jul 25, 2009 at 7:49 PM, Sam Masons...@samason.me.uk wrote: On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote: On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote: I thought the whole point of MAC was that superusers don't exist any more--at least not with the power they currently do. It's been billed that way, but it's not really accurate. A more accurate statement would be that it's possible to create a system in which there is no unconfined role. Yes, that sounds more precise! I'm still unsure of terminology; what's a unconfined role? I guess the layman's description is similar to a superuser, but I'm sure there's a more refined definition somewhere. Hum, I've just found Fedora's guide, is the following considered a reasonable picture: http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html Organizations may well not trust specific parts of their database to certain types of backups, SE-PG should allow this to be controlled somewhat. I imagine it would be possible to run pg_dump on a database where you couldn't see all of the objects, and get a dump of just those, but that's only tangentially related to whether such things as superusers exist. I'm not sure what point you're trying to make; in my understanding superusers can see and do anything--hence they can make a backup. If superusers DON'T exist, that would be making the opposite statement, namely, that there isn't ANY WAY to get a backup that you can be sure DOES contain all of the objects. The traditional approach would be to maintain multiple physically separate databases; in this setup it's obvious that when you perform a backup of one of these databases you're only seeing a subset of all of the objects. Isn't SE-PG just allowing you to do this within a single PG database? Partly. There's also a concept called read down, which is important. It allows you to have, say, secret and classified data in the same database, and let the secret users see both types but the classified users see only the classified stuff, not the secret stuff. If you want to store intelligence data about the war in Iraq and intelligence data about the war in Afghanistan, it might not be too bad to store them in separate databases, though storing them in the same database might also make things simpler for users who have access to both sets of data. But if you have higher and lower classifications of data it's pretty handy (AIUI) to be able to let the higher-secrecy users read the lower-secrecy data - if you used separate databases to simulate read-down, you'd have to replicate data between them, and also have some manual mechanism for tracking which level of secrecy applied to which to which data. All of the foregoing is my very layman's understanding of this, so take it with a grain of salt. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
On Sat, Jul 25, 2009 at 11:38 PM, Pavel Stehulepavel.steh...@gmail.com wrote: Hello 2009/7/25 Robert Haas robertmh...@gmail.com: On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehulepavel.steh...@gmail.com wrote: 2009/4/18 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: 2009/4/11 Tom Lane t...@sss.pgh.pa.us: No, I was complaining that a hook right there is useless and expensive. transformExpr() is executed multiple times per query, potentially a very large number of times per query; so even testing to see if a hook exists is not a negligible cost. I did some tests based on pgbench. The queries done by pgbench are completely trivial and do not stress parser performance. Even if they did (consider cases likw an IN with a few thousand list items), the parser is normally not a bottleneck compared to transaction overhead, network round trips, and pgbench itself. I though about different position of hook, but only in this place the hook is useful (because expressions are recursive). As I keep saying, a hook there is useless, at least by itself. You have no control over the grammar and no ability to modify what the rest of the system understands. The only application I can think of is to fool with the transformation of FuncCall nodes, which you could do in a much lower-overhead way by hooking into transformFuncCall. Even that seems pretty darn marginal for real-world problems. I am sending modified patch - it hooking parser via transformFuncCall I am reviewing this patch. It seems to me upon rereading the thread that the objections Tom and Peter had to inserting a hook into transformExpr() mostly still apply to a hook in transformFuncCall(): namely, that there's no proof that putting a hook here is actually useful. I think we should apply the same criteria to this that we have to some other patches that have been rejected (like the extensible-rmgr patch Simon submitted for CommitFest 2008-11), namely, requiring that the extension mechanism be submitted together with at least two examples of how it can be used to interesting and useful things, bundled as one or more contrib modules. I have in my plan add to contrib JSON support similar to Bauman design: http://www.mysqludf.org/lib_mysqludf_json/index.php It's will be sample of smart functions. Because this need more then less work I am waiting on commit. Other simple intrduction contrib module should be real Oracle decode function - I sent source code some time ago. But this code needs some modification. I should send this code if you need it. Sure, post it and let's discuss. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mixed, named notation support
Hi,
I sending a little bit modified version - I removed my forgotten
comment in gram.y
Regards
Pavel
2009/7/25 Pavel Stehule pavel.steh...@gmail.com:
Hello,
fixed patch attached + more regress tests.
Regards
Pavel Stehule
2009/7/23 Pavel Stehule pavel.steh...@gmail.com:
2009/7/23 Bernd Helmle maili...@oopsware.de:
--On Donnerstag, März 05, 2009 08:41:28 +0100 Pavel Stehule
pavel.steh...@gmail.com wrote:
Hello
I did some cleaning on this feature, and I hope so I solve some Tom's
objections
features:
* PostgreSQL's specific syntax for named parameter: value AS name,
* Doesn't change rules for defaults,
* Get defaults for named, mixed notation in planner time.
Pavel, consider the following function:
CREATE OR REPLACE FUNCTION ftest(a int, b text)
RETURNS RECORD
LANGUAGE SQL
AS
$$
SELECT $1, $2 ;
$$;
#= SELECT ftest('blubb' AS b, 128 AS a);
ERROR: function ftest(unknown, integer) does not exist at character 8
#= SELECT ftest(128 AS a, 'abcd' AS b);
ftest
(128,abcd)
(1 row)
Isn't the first one supposed to work?
it is probably bug. I'll look on it tomorrow.
Pavel
--
Thanks
Bernd
named-fixed.diff.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
Sam Mason wrote: On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote: On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote: I thought the whole point of MAC was that superusers don't exist any more--at least not with the power they currently do. It's been billed that way, but it's not really accurate. A more accurate statement would be that it's possible to create a system in which there is no unconfined role. Yes, that sounds more precise! Yes, Rober's explanation is correct. I'm still unsure of terminology; what's a unconfined role? I guess the layman's description is similar to a superuser, but I'm sure there's a more refined definition somewhere. Hum, I've just found Fedora's guide, is the following considered a reasonable picture: http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html Please note that SELinux/SE-PgSQL checks all the requests from users without any exceptions, even if he is a superusers. It makes its access control decisions based on the security policy. The default security policy (which is provided by SELinux's community) allows anything on the unconfined ones. Thus, it is allowed anything at the result. (Needless to say, DAC permission checks are applied independent from whether it is confined or unconfined in SELinux.) It is important the decision is always according to the security policy. And while I believe SE-Linux/SE-PostgreSQL would allow you to configure such a system, you might want to think carefully before you decide to do so, and the system certainly shouldn't (and can't) force you to set it up that way. I agree that this would seem to make the resulting system easier to manage, however I can also imagine scenarios where the converse would be true. This is a fuzzy engineering decision of the sort that I don't like making without a use case---and it would be nice to have several here. The SELinux provides a certain process privilege to make backups and restore them. In the (currect) default policy, it is called unconfined. However, it is also *possible* to define a new special process privilege for backup and restore tools. For example, it can access all the databse objects and can make backups, but any other process cannot touch the backup files. It means that DBA can launch a backup tool and it creates a black-boxed file, then he cal also lauch a restore tool to restore the black-boxed backup, but he cannot see the contents of the backup. (It might be a similar idea of sudo mechanism.) It is a separated issue whether the *default* security policy should supports such an extreme protection, or not. However, SELinux community shall provide its security policy to make backup and restore them correctly, and suggest what privilege should be assigned on the user sheel which launches backup and restore tools. If it does not work correctly, it is a simply bug. TODO: I've not provide a draft documentation for backup options to pg_dump command, but it will be necessary to be reviewed. It should contains what security context should be assigned on the user shell which launches the pg_dump also. Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PostgreSQL Specifications
Robert Haas wrote: If superusers DON'T exist, that would be making the opposite statement, namely, that there isn't ANY WAY to get a backup that you can be sure DOES contain all of the objects. The traditional approach would be to maintain multiple physically separate databases; in this setup it's obvious that when you perform a backup of one of these databases you're only seeing a subset of all of the objects. Isn't SE-PG just allowing you to do this within a single PG database? Partly. There's also a concept called read down, which is important. It allows you to have, say, secret and classified data in the same database, and let the secret users see both types but the classified users see only the classified stuff, not the secret stuff. If you want to store intelligence data about the war in Iraq and intelligence data about the war in Afghanistan, it might not be too bad to store them in separate databases, though storing them in the same database might also make things simpler for users who have access to both sets of data. But if you have higher and lower classifications of data it's pretty handy (AIUI) to be able to let the higher-secrecy users read the lower-secrecy data - if you used separate databases to simulate read-down, you'd have to replicate data between them, and also have some manual mechanism for tracking which level of secrecy applied to which to which data. It seems a correct description. In addition, we also need to prevent that higher-secrecy users writes anything to the lower-secrect objects to prevent information leaks. In some cases, the clearance of infoamtion may be changed. We often have dome more complex requirements also. Thus, it is necessary a capability to store and manage data objects with different security labeles in a single database instance here. (If we don't want to use commercial solutions instead.) Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
