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 Query node
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
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
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 or
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) can
#! /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 not help,
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
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, optimal would imho also
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 need
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. It
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 a
#! /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 not
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 to aquire
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 to do
[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
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 macros and
Phillip Jansen [EMAIL PROTECTED] writes:
!doctype html public -//w3c//dtd html 4.0 transitional//en
html
Hi
pI trying to compare oracle vs postgresql , so Inbsp;have a table containing
about 7.6 mil records but every time Inbsp;try to do a simple select on
the table it throws a core dump
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 passwords in
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.
What
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 or
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
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, AFAIK.
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
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 from
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's
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 type interface ?
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 cleaned
27 matches
Mail list logo
