Re: [PATCHES] NUMERIC key word
Peter Eisentraut <[EMAIL PROTECTED]> writes: > In 8.3, it appears that NUMERIC doesn't need to be a key word any longer. > See > attached patch. Was there a reason this was kept in the parser? Otherwise > we could remove it in 8.4. The reason it was kept was to override the search path --- unqualified NUMERIC will always be taken as pg_catalog.numeric even if you have some other type "numeric" in front of it. I believe we had concluded that this behavior is required by the SQL spec. In any case, it would be kinda weird for DECIMAL to have that behavior and NUMERIC not. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] NUMERIC key word
In 8.3, it appears that NUMERIC doesn't need to be a key word any longer. See
attached patch. Was there a reason this was kept in the parser? Otherwise
we could remove it in 8.4.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
diff -ur ../cvs-pgsql/src/backend/parser/gram.y ./src/backend/parser/gram.y
--- ../cvs-pgsql/src/backend/parser/gram.y 2008-01-04 15:55:24.0 +0100
+++ ./src/backend/parser/gram.y 2008-01-29 16:00:59.0 +0100
@@ -412,7 +412,7 @@
NAME_P NAMES NATIONAL NATURAL NCHAR NEW NEXT NO NOCREATEDB
NOCREATEROLE NOCREATEUSER NOINHERIT NOLOGIN_P NONE NOSUPERUSER
- NOT NOTHING NOTIFY NOTNULL NOWAIT NULL_P NULLIF NULLS_P NUMERIC
+ NOT NOTHING NOTIFY NOTNULL NOWAIT NULL_P NULLIF NULLS_P
OBJECT_P OF OFF OFFSET OIDS OLD ON ONLY OPERATOR OPTION OR
ORDER OUT_P OUTER_P OVERLAPS OVERLAY OWNED OWNER
@@ -6986,12 +6986,6 @@
$$->typmods = $2;
$$->location = @1;
}
- | NUMERIC opt_type_modifiers
-{
- $$ = SystemTypeName("numeric");
- $$->typmods = $2;
- $$->location = @1;
-}
| BOOLEAN_P
{
$$ = SystemTypeName("bool");
@@ -9266,7 +9260,6 @@
| NCHAR
| NONE
| NULLIF
- | NUMERIC
| OUT_P
| OVERLAY
| POSITION
diff -ur ../cvs-pgsql/src/backend/parser/keywords.c ./src/backend/parser/keywords.c
--- ../cvs-pgsql/src/backend/parser/keywords.c 2008-01-04 15:55:24.0 +0100
+++ ./src/backend/parser/keywords.c 2008-01-29 16:01:09.0 +0100
@@ -251,7 +251,6 @@
{"null", NULL_P, RESERVED_KEYWORD},
{"nullif", NULLIF, COL_NAME_KEYWORD},
{"nulls", NULLS_P, UNRESERVED_KEYWORD},
- {"numeric", NUMERIC, COL_NAME_KEYWORD},
{"object", OBJECT_P, UNRESERVED_KEYWORD},
{"of", OF, UNRESERVED_KEYWORD},
{"off", OFF, RESERVED_KEYWORD},
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] WIP: plpgsql source code obfuscation
On 29/01/2008, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Am Montag, 28. Januar 2008 schrieb Pavel Stehule: > > this patch define new function flag - OBFUSCATE. With this flag > > encrypted source code is stored to probin column. Password is stored > > in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server > > does (where privileged users can access system tables with source code > > or can use debugger). > > Have you thought about a solution that applies the regular access privileges > to pg_proc in order to hide some content from less privileged users? it's second way, and maybe better. It can close way to table definitions too (and this request is adequate too). But you cannot to hide complete column, visibility depend on content and it can be slow, complex :(. Encrypt, decrypt aren't fast too. Pavel > > -- > Peter Eisentraut > http://developer.postgresql.org/~petere/ > ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] WIP: plpgsql source code obfuscation
Peter Eisentraut wrote: Am Montag, 28. Januar 2008 schrieb Pavel Stehule: this patch define new function flag - OBFUSCATE. With this flag encrypted source code is stored to probin column. Password is stored in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server does (where privileged users can access system tables with source code or can use debugger). Have you thought about a solution that applies the regular access privileges to pg_proc in order to hide some content from less privileged users? This question is a good one, especially since we have waiting in the wings the work my SOC student did a few months ago on column level privileges. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] WIP: plpgsql source code obfuscation
Am Montag, 28. Januar 2008 schrieb Pavel Stehule: > this patch define new function flag - OBFUSCATE. With this flag > encrypted source code is stored to probin column. Password is stored > in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server > does (where privileged users can access system tables with source code > or can use debugger). Have you thought about a solution that applies the regular access privileges to pg_proc in order to hide some content from less privileged users? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] WIP: plpgsql source code obfuscation
Am Montag, 28. Januar 2008 schrieb Tom Lane: > My recollection is that certain cryptography laws make hooks for crypto > just as problematic as actual crypto code. We'd have to tread very > carefully --- "general purpose" hooks are OK but anything narrowly > tailored to encryption purposes would be a hazard. PostgreSQL already has built-in support for SSL and Kerberos, so it is already infested with enough weaponized code to fail most applicable regulations. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Gregory Stark wrote: "Kris Jurka" <[EMAIL PROTECTED]> writes: On Mon, 28 Jan 2008, Jeff Davis wrote: I think that pg_dump is a reasonable use case for synchoronized scans when the table has not been clustered. It could potentially make pg_dump have much less of a performance impact when run against an active system. One of the advantages I see with maintaining table dump order is that rsyncing backups to remote locations will work better. I can't see what scenario you're talking about here. pg_dump your live database, restore it elsewhere, then shut down the production database and run rsync from the live database to the restored one? Why not just run rsync for the initial transfer? take a dump (maybe in plaintext format) save it to disk and use rsync to copy it elsewhere. the more "similiar" the dumps the more efficient rsync can copy the data over. Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
"Kris Jurka" <[EMAIL PROTECTED]> writes: > On Mon, 28 Jan 2008, Jeff Davis wrote: > >> I think that pg_dump is a reasonable use case for synchoronized scans >> when the table has not been clustered. It could potentially make pg_dump >> have much less of a performance impact when run against an active >> system. > > One of the advantages I see with maintaining table dump order is that rsyncing > backups to remote locations will work better. I can't see what scenario you're talking about here. pg_dump your live database, restore it elsewhere, then shut down the production database and run rsync from the live database to the restored one? Why not just run rsync for the initial transfer? I can't see that working well for a real database and a database loaded from a pg_dump anyways. Every dead record will introduce skew, plus page headers, and every record will have a different system data such as xmin for one. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 6: explain analyze is your friend
