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 --- u
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 ./sr
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
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 priv
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
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 b
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 a
"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 ac
