At 19:49 27/06/01 -0400, Tom Lane wrote:
>
>Hmm. [sound of grepping] So does psql's \lo_list command. That's
>annoying ... the list of large object OIDs is *exactly* what you'd want
>to hide from the unwashed masses. Oh well, I'll leave bad enough alone
>for now.
>
I suspect this would be cle
At 23:55 27/06/01 +0200, Peter Eisentraut wrote:
>Hannu Krosing writes:
>
>> > > Is there an ISO/ANSI SQL interface to BLOB's defined someplace ?
>> >
>> > It's basically no different from regular character strings, i.e.,
>> > substring(), position(), ||, etc.
>>
>> So no standard seek/read/write
Philip Warner <[EMAIL PROTECTED]> writes:
> At 12:27 27/06/01 -0400, Tom Lane wrote:
>> I propose that initdb should do
>> REVOKE ALL on pg_largeobject FROM public
> May have an issue with PG_DUMP, which does a 'select oid from
> pg_largeobject', I think.
Hmm. [sound of grepping] So does psql'
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It seems fairly ugly to have a pg_class entry for something that
>> isn't a table or even a table-like entity.
> I dont think that sequence is any more table-like than record.
Oh? It's got storage, it's got columns, you can select
At 12:27 27/06/01 -0400, Tom Lane wrote:
>I propose that initdb should do
> REVOKE ALL on pg_largeobject FROM public
>
May have an issue with PG_DUMP, which does a 'select oid from
pg_largeobject', I think.
Philip Warner
"Frank Ch. Eigler" <[EMAIL PROTECTED]> writes:
> Oh, I see finally. You already put a custom little
> challenge/response authentication scheme into postgresql,
> and want to keep that working. (May I ask when/why that
> went in at all?
Long before any of the current generation of developers, AF
I propose that initdb should do
REVOKE ALL on pg_largeobject FROM public
same as it does already for pg_shadow and pg_statistic. This would
prevent non-superusers from examining or modifying large objects
except through the LO operations.
This is only security through obscurity, of cours
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> What for/why bother? A toastable bytea column would do just as well.
> There's still a 1 or 2 GB limit for data stored in that.
1 Gb, I believe ... but LOs are not a lot better; they'd max out at 2 or
at most 4 Gb, depending on
Jan Wieck <[EMAIL PROTECTED]> writes:
> 1. Adding a new relkind that means 'record'. So we use
> pg_class, pg_attribute and pg_type as we do for tables
> and views to describe a structure.
It seems fairly ugly to have a pg_class entry for something that
isn't a table
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
> Please, consider a BLOB column type without having to do lo_import,
> lo_export.
>>
>> Yep, big needed item.
> Maybe we could make the BLOB type a wrapper around the lo_* functions?
> The BLOB value would only store the oid.
"Frank Ch. Eigler" <[EMAIL PROTECTED]> writes:
> Having scanned over the discussion again, my understanding is that Jim's
> proposed changes don't affect backwards compatibility. As long as user
> passwords continue to be passed in plaintext to the server, the server
> can store encrypted passwor
Phillip Jansen <[EMAIL PROTECTED]> writes:
>
>
> Hi
> I trying to compare oracle vs postgresql , so I have a table containing
> about 7.6 mil records but every time I try to do a simple select on
> the table it throws a core dump and segmentation fault. At first it returns
> "backend returns D
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> any points to convert textout and textin to 7.1 ?
> Look in src/backend/utils/adt/ for examples of functions called from
> within other functions. You will want to upgrade to the new calling
> convention for functions, and will need to use some macro
[EMAIL PROTECTED] (Frank Ch. Eigler) writes:
> tgl wrote:
> : What this discussion seems to come down to is whether we should take a
> : backward step in one area of security (security against wire-sniffing)
> : to take a forward step in another (not storing plaintext passwords).
> It seems to me
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Alex Pilosov wrote:
>> On Tue, 26 Jun 2001, Reinoud van Leeuwen wrote:
> 1: will it be possible to return multiple result sets? (in Sybase any
> select statement that is not redirected to variables or a table goes
> to the client, so it is quite common t
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > In my understanding the deadlock check is performed every time the
> > backend aquires lock. Once the it aquires, it kill the timer. However,
> > under heavy transactions such as pgbench generates, chances are that
> > the checking fires, and it tries
hello,
trying to migrate production servers form 7.0.2 to 7.1.1 now I need to
compile an function written in c and when compiling using following
includes:
#include
#include
#include
#include
I get following compile errors:
c:82: warning: passing arg 1 of `textout' from incompatible pointe
> > #! /bin/sh
> > pgbench -i -s 2 test
> > for i in 1 2 4 8 16 32 64 128
> > do
> > t=`expr 640 / $i`
> > pgbench -t $t -c $i test
> > echo "= sync =="
>
> With 7.1 you will probably want a checkpoint instead of sync here:
> psql -c "checkpoint;" template1 ; sleep 10
>
On Wed, Jun 27, 2001 at 08:42:07AM -0400, Alex Pilosov wrote:
> On Wed, 27 Jun 2001, Karel Zak wrote:
> This is a little bit better, but, results in following syntax:
> GRANT SELECT ON FOO(int4). I'm not sure if this really makes sense. Its
> not a select permission, its an execute permission on
On Wed, Jun 27, 2001 at 06:54:27AM -0400, Alex Pilosov wrote:
> On Wed, 27 Jun 2001, Karel Zak wrote:
>
> > On Wed, Jun 27, 2001 at 10:56:43AM +0200, Reinoud van Leeuwen wrote:
> > > >
> > > >> For the result from foo() you must somewhere define attributes
> > > >> (names).
> > > >> Where? In
> > For the result from foo() you must somewhere define attributes (names).
> > Where? In CREATE FUNCTION statement? Possible must be:
> Function must be returning an existing reltype. I understand its a major
> restriction, but I can't think of a better way.
Yup, that's how Informix does it.
> > In my setup the function would be hidden by a view.
> Its a different problem. Functions returning tables do just that, return
> tables, they won't care just what from that table you need. Exposing
> pieces of optimizer to your function doesn't seem to me like a great
> idea...
Ok, I think i
On Wed, Jun 27, 2001 at 10:56:43AM +0200, Reinoud van Leeuwen wrote:
> >
> >> For the result from foo() you must somewhere define attributes
> >> (names).
> >> Where? In CREATE FUNCTION statement? Possible must be:
> >>
> >> select name1, name2 from foo() where name1 > 10;
> >
> > Yes, opti
> >> For the result from foo() you must somewhere define attributes (names).
> >> Where? In CREATE FUNCTION statement? Possible must be:
> >>
> >> select name1, name2 from foo() where name1 > 10;
> >
> > Yes, optimal would imho also be if the foo() somehow had access to the
> > where restric
> #! /bin/sh
> pgbench -i -s 2 test
> for i in 1 2 4 8 16 32 64 128
> do
> t=`expr 640 / $i`
> pgbench -t $t -c $i test
> echo "= sync =="
With 7.1 you will probably want a checkpoint instead of sync here:
psql -c "checkpoint;" template1 ; sleep 10
The sync does
> On Tue, Jun 26, 2001 at 10:18:37AM -0400, Tom Lane wrote:
> > though I would note that anyone who is able to examine the
> > contents of pg_shadow has *already* broken into your database
>
> note: the dbadmin may not be the system administrator, but the dbadmin,
> by default (with plaintext) c
> Let's consider some simple example:
>
> create table tst ( a int4, b int4, c int4);
>
> select * from tst where a=2 and c=0;
>
> we need something like:
>
> select * from tst where str and c=0;
>
> where str is a string resulting by call ourfunc(table.a, 2)
> and looks like 'b=2*2
>
>> For the result from foo() you must somewhere define attributes
>> (names).
>> Where? In CREATE FUNCTION statement? Possible must be:
>>
>> select name1, name2 from foo() where name1 > 10;
>
> Yes, optimal would imho also be if the foo() somehow had access to the
> where restriction, so
> For the result from foo() you must somewhere define attributes (names).
> Where? In CREATE FUNCTION statement? Possible must be:
>
> select name1, name2 from foo() where name1 > 10;
Yes, optimal would imho also be if the foo() somehow had access to
the where restriction, so it could only p
On Tue, Jun 26, 2001 at 05:11:47PM -0400, Alex Pilosov wrote:
> I started thinking about Tom's idea to implement functions as table
> source.
>
> To me, it seems that a very few changes are necessary:
> a) parser must be changed to allow functioncall to be a table_ref
> (easy)
>
> b) when a Quer
30 matches
Mail list logo
