Re: [HACKERS] PostgreSQL and SOAP, suggestions?
On Thu, Apr 03, 2003 at 07:54:13AM -0500, [EMAIL PROTECTED] wrote: I have been planning to test the whole thing with a few .NET applications. I am currently using expat to parse the output to ensure that it all works correcty. That, unfortunately, probably implies that your implementation is almost totally non-interoperable. You should put out of your mind the notion of being correct. Being correct is pretty irrelevant if 80% of the requests that come from a VB.NET client fail because Microsoft implemented part of their request differently than what you interpreted as correct. The point is that correctness isn't the thing you need to aim for; what you should aim for is interoperability with the important client implementations. SOAP::Lite, .NET, probably some Java ones, C++ ones, and such. Nobody does correctness testing; they do interoperability tests where they try to submit requests to Apache AXIS, .NET, WebSphere, and the lot of other important implementations. If you're testing a server (as is the case here), then the point is to run tests with a bunch of clients. Head to the SOAP::Lite and Axis projects; you'll see matrices describing this sort of thing... Hmmm. Can I reiterate my support of XML-RPC here? g -Jay 'Eraserhead' Felice -- (reverse (concatenate 'string ac.notelrac.teneerf@ 454aa)) http://www.ntlug.org/~cbbrowne/advocacy.html Fear leads to anger. Anger leads to hate. Hate leads to using Windows NT for mission-critical applications. --- What Yoda *meant* to say ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL and SOAP, version 7.4/8.0
First, a SOAP query should be posted in SOAP message format, not using the
query string as you do. Second, I like the idea of calling external SOAP
services, but consider creating a language 'soap' you could do with a CREATE
FUNCTION type thing. e.g.
CREATE FUNCTION foo (TEXT) RETURNS INTEGER AS
'http://somewhere.com/path/to/.wsdl', 'foo'
LANGUAGE 'soap';
(hmm, it is unclear if this is what you are suggesting or not...)
Second, I hate SOAP because it is too bloated (have you read the spec(s)?).
If you can support xmlrpc instead, you'll save yourself a lot of headaches.
If you got SOAP working, though, I'd use it. It's more an implementation
thing.
On Fri, Mar 28, 2003 at 09:01:08AM -0500, mlw wrote:
I have been working on moving some of my software to a more SOAP
compatible interface. As I was doing it, it occured to me that a generic
function could be written, in PostgreSQL's new function manager that
allows multiple columns to be returned, that is a generic SOAP interface.
All one would need do is define what is expected from the SOAP call in
the CREATE FUNCTION statement. Then the generic SOAP function could
then read what is expected and return the XML/SOAP data as a set of
results as if it were a subquery.
What is needed is an efficient way to find the data types and names from
the functions definition. Does anyone know how to do that?
A small program could also parse a WSDL file and write a CREATE
FUNCTION script for the XML as well.
On the flip side, I am also working on a PostgreSQL SOAP interface,
where one does this:
http://somehost/postgresql?query=select * from table
And a SOAP compatible resultset is returned.
On a more advanced horizon, one should be able to do this:
select * from localtable,
mysoap('http://remotehost/postgresql?query=select * from foo') as soap
where soap.field = localtable.field;
If we can do that, PostgreSQL could fit into almost ANY service
environment. What do you guys think? Anyone want to help out?
I have no time to volunteer for projects, but what the hell...! It's too
cool. I can't spend much time on it but bounce things off me and I'll
do whatever hacking I can squeeze in. What soap implementation would you
use for the PostgreSQL plugin? libsoap, last I checked, is a wee bit
out of date. And not documented.
-Jason
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL and SOAP, version 7.4/8.0
On Fri, Mar 28, 2003 at 01:36:43PM -0500, [EMAIL PROTECTED] wrote: Of course, CORBA has actually been quite formally standardized, suffers from many fairly interoperable implementations, and is rather a lot less bloated than any of the XML-based schemes. It might be worth trying, too... The ability to use the HTTP transport has it's advantages with web services-- You can throw something together with a few lines of PHP, you don't have to worry about how to activate objects, I've never been able to figure out how to handle transport-layer security and authentication with CORBA (of course, this was all fairly new stuff when I was working with it), all this stuff comes for free with the HTTP transport. I like CORBA, though, and I'd probably find a CORBA module useful, but it doesn't solve all the same problems. Hrm, I wonder if the overhead of XML-RPC wouldn't be too bad for the new PostgreSQL protocol... it probably would, but it would be entirely useful. You can make XML-RPC calls from mozilla javascript, so you could do some pretty sweet tweaking to keep your addresses in a pgsql database. As an additional protocol which postmaster can listen to it would rule. I'm making a habit of putting all the business logic into stored procedures, and this would basically publish the business logic in a very useful way. -Jason ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] EXPLAIN ANALYZE in comparable units
I'm curious if anyone's considered adding logic to count actual disk/cache hits to report for EXPLAIN ANALYZE so that we get a more apples-to-apples comparison? The other question is whether anyone has got scripts or tools or what not for testing and getting accurate numbers for the following tuning variables: random_page_cost cpu_tuple_cost cpu_index_tuple_cost cpu_operator_cost I've seen the code and the last one is pretty gross, but the first three could definitely swing the optimizer, especially with the hardware I might be getting ;-) If noone has scripts, can anyone suggest how to implement. -Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SQL99 ARRAY support proposal
On Mon, Mar 10, 2003 at 09:49:47AM -0500, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Joe Conway kirjutas E, 10.03.2003 kell 05:35:
CREATE OR REPLACE FUNCTION array_push (anyarray, anyscalar)
RETURNS anyarray
could you make it
RETURNS typeof($1)
Not directly --- we have to fit the return-type info into an OID field.
We could fake it by inventing one or more pseudotypes, SAMEASPARAMn.
But I think I like better the notion of extending my bound-together-
ANYARRAY-and-ANYELEMENT proposal,
http://archives.postgresql.org/pgsql-hackers/2003-03/msg00319.php
Suppose that we do that, and then further say that ANYARRAY or
ANYELEMENT appearing as the return type implies that the return type
is actually the common element or array type. Then we have such
useful behaviors as:
array_push(anyarray, anyelement) returns anyarray
array_pop(anyarray) returns anyelement
array_subscript(anyarray, int) yields anyelement
singleton_array(anyelement) yields anyarray
The last three cases cannot be handled by a SAMEASPARAM construct.
... typeof($1)[], or a ARRAYELEMSAMEASPARAM construct?
I'm really liking this discussion. I know this is sort of out there, but
I have found in languages like StandardML and Objective CAML that templatized-
type functions are _extremely_ useful. These languages type systems are
amazingly powerful (the language syntax is another matter *sigh*).
I'm not necessarily suggesting implementing this, but I just want to feed the
debate a bit. I view the type system of these guys as the ideal, and would
be in ecstacy if PostgreSQL had it, but I realize implementing the thing would
prolly be far from practical.
First, there are templatized types. Arrays in PostgreSQL are sort of a
kludge of templatized types, but they would be defined like so:
type a' array = some definition ...
which means that you are describing an array of some type a' (the apostrophe
indicates a type variable).
You can also create other neat templatized types as an aside:
type a' Nullable = Null | Value of a'
Which means the expressions:
Value 47 -- of type int Nullable
Null -- of type a' Nullable (determined from context)
But then, you could also say:
int array array
Or even:
int Nullable array
Which is somthing you can't in PostgreSQL but would be very nice. But then
you could say:
let invert_matrix m : a' array array - a' array array = code...
let multiply x : a', y : a' - a' = code ...
You could have more than one type variable in a templatized type or function,
true, but I've never really needed more than one. I can imagine cases where
it would be useful, but just haven't needed one.
Plus:
* get rid of horrible 'int4_' type hacks for array.
Minus:
* can't use oid to represent exact type, rather a string of oids.
* need second table to hold function type constraints when function
is templatized. (or could make it params oid array array, aka
oid[][]!) Reserve eight or ten oids for template parameter slots
(in other words, for a' through j' or something).
Warning: I have been called the type nazi g
One other thing from StandardML that I have always wanted in PostgreSQL
(or anywhere else I program, for that matter)- record types. (Warning, this is
also very wishful thinking and out there).
In ML/CAML, a record type is defined like so:
type myrecord = {
x : int,
y : int,
s : string
};
myrecord is actually just type alias, the canonical record definition is:
{s:string, x:int, y:int}
... with the attributes in alphabetical order, because unless you are mucking
with pointers in C, it really doesn't matter what order they are in. The
first advantage become very apparent: Any two records with the same named
attributes of the same types are always of the same type. In PostgreSQL,
this would mean that functions that operate on RECORD{x:int,y:int,s:string}
could operate on a record from any relation with those attributes.
Further, to make inheritance pretty much unnecesary, you could allow a
record with more attributes to satisfy a parameter or return value constraint.
In other words, you could call function foo(RECORD{x:int,y:int}) on a
RECORD{s:string,x:int,y:int}.
I've thought about this trick a lot. In theory there is a possibility of
not getting what you want, but in practice it would almost never happen. The
demostrative case would be calling distance_from_origin(RECORD{x:int,y:int})
on RECORD{x:int,y:int,z:int}, but in this case you need to make a
distance_from_origin(RECORD{x:int,y:int,z:int}).
This way, you could make a function which operates on RECORD{oid:oid} which
could be called on any record from a table. I've wanted to do this sort of
thing on several occasions- one application has notes which can be attached
to any row, sort of like PostgreSQL comments. Another to keep track of what
user
[HACKERS] Query planner/stored procedure cost
Hello... I haven't been subscribed in a while, but I've got an issue and am trying to determine if the Right Way(tm) is the quickest way to fix it. Basically, I have some very expensive stored procedures that determine whether a user should have access to particular rows in a query (not a postgresql user, we only use one postgresql user... the user is passed as a parameter to the function). The logic--per row--contains about a dozen queries and probably averages eight queries per run, with short-circuiting and all. So it is _very_ expensive. Given that I use this function in lots of queries with hairy joins and all, I'd much like for the optimizer to know what to do with the function. Empirically, I deduce that the optimizer treats all procedures as inexpensive (it seems to always just tack it on to the `Filter' slot when scanning the related table). Currently I'm using stored procedures returning multiple rows to get around the planner on these and defer the expensive procedure until the last possible moment (so that joins and other table criteria have a chance to filter out a lot of records). This typically shaves 75% of the time off of these queries. So, the question is: What am I looking at in doing the following: 1) Adding a mechanism to tell PostgreSQL how expensive a procedure is (a system table which can be updated manually, or an existing system table if there is a logical place for it). 2) Updating the planner to consider the procedure's cost in estimates. 3) Changing the query planner to consider bubbling up the function to an outer filter slot. Possibly, also: 4) Changing the planner to order expressions in a `Filter' slot by cost. although I don't mind doing this manually and I know the order can determine which indices PostgreSQL uses. I'm still mulling it over, and I'm guessing the real problem here is if it is a wise generalization that we can bubble-up the function. What if the function has side effects? Does this break? We can at least do procedures with `iscachable' flag. Disclaimer: I haven't every really hacked the planner code, but I have a good feel for how it works from lots and _lots_ of experience with it g -Jay 'Eraserhead' Felice ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
