Re: [HACKERS] Beta5 in ~4 hours ...

[Reini Urban]

Marc G. Fournier schrieb:
Just as a heads up, I'm going to roll it in about 4hrs (~02:00GMT) ...
I checked a couple of mirrors this morning and only the swedish one got 
it so far. (timestamps 03:24 - 03:36)
Maybe it would be better next time to upload it before 0:00 GMT
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[HACKERS] Beta5 now Available

[Marc G. Fournier]

Check her out and let me know if there are any problems ... I've changed 
the mk script to pull in the beta3 man pages that I found  in the dev/doc 
directory ...


Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664
---(end of broadcast)---
TIP 3: 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: [Testperf-general] Re: [HACKERS] ExclusiveLock

[Simon Riggs]

On Sat, 2004-11-20 at 16:14, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2004-11-18 at 22:55, Tom Lane wrote:
> >> If it is a problem, the LockBuffer calls in RelationGetBufferForTuple
> >> would be the places showing contention delays.
> 
> > You say this as if we can easily check that.
> 
> I think this can be done with oprofile ...

OK, well thats where this thread started.

oprofile only tells us aggregate information. It doesn't tell us how
much time is spent waiting because of contention issues, it just tells
us how much time is spent and even that is skewed.

There really ought to be a better way to instrument things from inside,
based upon knowledge of the code.

-- 
Best Regards, Simon Riggs


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Beta5 in ~4 hours ...

[Bruce Momjian]

Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Just as a heads up, I'm going to roll it in about 4hrs (~02:00GMT) ...
> 
> Works for me.  I've got two small patches I'm about to commit, and then
> I'll go update the release notes; should be done in an hour or two.

Fine by me.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Preventing some SQL commands

[Thomas Hallgren]

Tom Lane wrote:
... I would like to prevent the commands "begin [work or 
transaction]", "commit", and "rollback",  completely

If you are executing through SPI then those operations are disallowed
already.
 

Ah, yes I had forgotten that. One problem less to solve.
The main problem with this proposal is the erroneous assumption that
there can be only one command in a SPI plan.
 

Ok, so let the function return a list of CmdType's terminated by the 
CMD_UNKNOWN (i assume that's an invalid value). The list should be 
pfree'd by the caller:

CmdType* SPI_get_command_types(void* executionPlan)
how about that?
Regards,
Thomas Hallgren

---(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] Preventing some SQL commands

[Thomas Hallgren]

James William Pye wrote:
Although, I'm inclined to think that if you require this sort of
flexibility you should probably think about writing your own SPI.
 

I think it's far better if we all focus our efforts to improve on the 
PostgreSQL SPI. That way, all PL's will benefit. That's the reason I 
submitted the SPI_is_cursor_plan, SPI_getargtypeid, and SPI_getargcount 
functions.

Regards,
Thomas Hallgren

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Beta5 in ~4 hours ...

[Tom Lane]

"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Just as a heads up, I'm going to roll it in about 4hrs (~02:00GMT) ...

Works for me.  I've got two small patches I'm about to commit, and then
I'll go update the release notes; should be done in an hour or two.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

[HACKERS] Beta5 in ~4 hours ...

[Marc G. Fournier]

Just as a heads up, I'm going to roll it in about 4hrs (~02:00GMT) ...

Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] New compile warnings

[Tom Lane]

Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I don't currently have the resources to clean this up properly. The 
> attached patch tries to make clear in a comment what the code is doing, 
> and also initializes these variables to NULL. If someone wants to take a 
> stab at cleaning this up they are welcome to - I don't expect to be able 
> to for quite a while.

OK, applied.  It compiles warning-free now for me (using Perl 5.8.0)

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Preventing some SQL commands

[James William Pye]

On Sun, 2004-11-21 at 16:55 +0100, Thomas Hallgren wrote:
> In a PL language it's sometimes desirable to prevent execution of some 
> commands. I would like to prevent the commands "begin [work or 
> transaction]", "commit", and "rollback",  completely and I would like to 
> force the user to use explicit methods for the savepoint methods.

I implemented my own SPI; not for this purpose, but I could [may] use it
for that.
This, of course, would also allow mapping specific utility commands to
my internal methods; instead of inhibiting them (tho, I don't do this
[yet, perhaps]).

> I wonder if there's any way to extract the nature of a command from the 
> execution plan returned by SPI_prepare. If not, would it be very 
> difficult to add? It doesn't feel optimal to add a home brewed parser 
> that parses the statements prior to prepare just to find out if I they 
> should prevented.
[snip]
> CmdType SPI_get_command_type(void* executionPlan)

[I see Tom's reply, but considering I already wrote this; here it is
anyways.]

Hrm, I can't help but think it would be better just to allow
fetching/access to the Node tag, (e.g. T_TransactionStmt) as opposed to
creating a new command type.

NodeTag SPI_get_utility_tag(void *execPlan);

Well, something like that. I suppose it would somehow need to handle
compound queries.

Perhaps a filter operation would be a better idea.
Passing a function pointer like:

bool (*SPI_UtilityFilter) (NodeTag aStmt);
To a "void SPI_FilterUtilities(void *execPlan, SPI_UtilityFilter fp)".

Throwing an error if deemed necessary by the pointed to function.

Although, I'm inclined to think that if you require this sort of
flexibility you should probably think about writing your own SPI.


While a ways from complete/stable, my Python "SPI":
http://gborg.postgresql.org/project/postgrespy/cvs/co.php/imp/src/query.c?r=HEAD
http://gborg.postgresql.org/project/postgrespy/cvs/co.php/imp/src/portal.c?r=HEAD

-- 
Regards,
James William Pye


signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Preventing some SQL commands

[Tom Lane]

Thomas Hallgren <[EMAIL PROTECTED]> writes:
> In a PL language it's sometimes desirable to prevent execution of some 
> commands. I would like to prevent the commands "begin [work or 
> transaction]", "commit", and "rollback",  completely and I would like to 
> force the user to use explicit methods for the savepoint methods.

If you are executing through SPI then those operations are disallowed
already.

> I wonder if there's any way to extract the nature of a command from the 
> execution plan returned by SPI_prepare. If not, would it be very 
> difficult to add?

The main problem with this proposal is the erroneous assumption that
there can be only one command in a SPI plan.

regards, tom lane

---(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] bug/issue tracking system?

[Robert Treat]

On Wednesday 17 November 2004 20:39, Arman Bostani wrote:
> I was wondering if there's a bug/issue tracking system for pgsql?  (e.g.
> something like http://www.bugzilla.org)  Is the TODO list all that there
> is?
>

There is no bugzilla interface, though it has been discussed in the past. 
Currently your best bet it to check the TODO list or check the mailing 
archives (pgsql-bugs in perticular) 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] OpenBSD/Sparc status

[Tom Lane]

"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I guess my concern is that on Sparc64/OpenBSD-3.6* at least, this bug is
> exposed by the seg tests but might well occur elsewhere and bite us in
> various unpleasant ways.

The experimentation I did to develop the test case suggested that the
problem only occurs when the result of a function returning float is
stored directly into a union member.  That's a sufficiently weird case
that I'm reasonably confident it doesn't occur elsewhere in the backend.
It might be worth Stefan's time to vary the test case a bit (eg try
double instead of float, struct instead of union, etc) and see just how
general the bug is.

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

[HACKERS] Fix for "q" with psql display paging dumps out of psql

[Jim Seymour]

Hi,

Environment:

SunOS 5.7 Generic_106541-29 sun4u sparc SUNW,UltraSPARC-IIi-Engine
Postgresql-7.4.6
Build config: --with-java --enable-thread-safety
gcc version 3.3.1
less-381
readline-4.3

$ echo $PAGER
/usr/local/bin/less
$ echo $LESS
-e

I recently upgraded from 7.4.2 to 7.4.6 and ran into an annoying
problem.  Thereafter, most times, "q"uitting out of paged display
output would dump me straight out of psql if the query result was
sufficiently large.

A bit of debugging revealed psql receiving a SIGPIPE to be the
problem.

Building pgsql w/o --enable-thread-safety eliminated the problem.

It looks like the culprit is asynchronous SIGPIPE signals under Solaris
7 when using thread-safe libraries.  Here's a reference:
.

I do not know if Solaris 8 and beyond behave this way.  (Apparently
async SIGPIPE is not POSIX-compliant, so one hopes Sun has fixed this
broken behaviour.)

Here's a fix that's simple, effective and doesn't hurt anything else:

- begin included text --
*** src/bin/psql/print.c-orig   Wed Nov 17 08:04:47 2004
--- src/bin/psql/print.cSat Nov 20 10:43:22 2004
***
*** 1119,1124 
--- 1119,1128 
{
pclose(output);
  #ifndef WIN32
+   /* The SIG_IGN is to compensate for broken Solaris 7
+* (async) SIGPIPE handling with --enable-thread-safety
+*/
+   pqsignal(SIGPIPE, SIG_IGN);
pqsignal(SIGPIPE, SIG_DFL);
  #endif
}
-- end included text ---

Thanks to Andrew, over at SuperNews, for the idea.

Regards,
Jim

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] How to check the postgresql version

[Thomas Hallgren]

Joe Conway wrote:
Along those lines, this is what I've been using in PL/R:
#if (CATALOG_VERSION_NO <= 200211021)
#define PG_VERSION_73_COMPAT
#elif (CATALOG_VERSION_NO <= 200310211)
#define PG_VERSION_74_COMPAT
#else
#define PG_VERSION_80_COMPAT
#endif
I wasn't following this thread earlier, but if you need to distinguish 
between, for example, 7.4.3 and 7.4.6, the above won't help. If you just 
need major Postgres version, it works well.

PL/Java used to have this in the Makefile.
SS_VERSION := $(subst ., ,$(subst devel,.devel,$(VERSION)))
PGSQL_MAJOR_VER = $(word 1,$(SS_VERSION))
PGSQL_MINOR_VER = $(word 2,$(SS_VERSION))
PGSQL_PATCH_VER = $(word 3,$(SS_VERSION))
override CPPFLAGS := \
-DPGSQL_MAJOR_VER=$(PGSQL_MAJOR_VER) \
-DPGSQL_MINOR_VER=$(PGSQL_MINOR_VER) \
-DPGSQL_PATCH_VER=$(PGSQL_MINOR_VER)
but I later removed the PGSQL_PATCH_VER since I don't plan to support 
different binaries for different patch levels. I'll try to do that using 
a more dynamic approach (i.e. through "SELECT version").

In the code, I do things like:
#if PGSQL_MAJOR_VER >= 8
or
#if PGSQL_MAJOR_VER == 7 && PGSQL_MINOR_VER < 3
Regards,
Thomas Hallgren
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

[HACKERS] Preventing some SQL commands

[Thomas Hallgren]

In a PL language it's sometimes desirable to prevent execution of some 
commands. I would like to prevent the commands "begin [work or 
transaction]", "commit", and "rollback",  completely and I would like to 
force the user to use explicit methods for the savepoint methods.

I wonder if there's any way to extract the nature of a command from the 
execution plan returned by SPI_prepare. If not, would it be very 
difficult to add? It doesn't feel optimal to add a home brewed parser 
that parses the statements prior to prepare just to find out if I they 
should prevented.

One approach could be to extend the CmdType enum. Perhaps something like 
this:

typedef enum CmdType
{
   CMD_UNKNOWN,
   CMD_SELECT,/* select stmt (formerly retrieve) */
   CMD_UPDATE,/* update stmt (formerly replace) */
   CMD_INSERT,/* insert stmt (formerly append) */
   CMD_DELETE,
   CMD_TRANSACTION,   /* begin, commit, rollback */
   CMD_SAVEPOINT, /* savepoint, rollback to savepoint, release 
savepoint */
   CMD_UTILITY,/* cmds like create, destroy, copy,
* vacuum, etc. */
   CMD_NOTHING/* dummy command for instead nothing 
rules
* with qual */
} CmdType;

and then add a SPI function
CmdType SPI_get_command_type(void* executionPlan)
What do you think? It would certanly help PL/Java add safe and efficient 
savepoint management and the other PL's are likely to share my concerns.

Regards,
Thomas Hallgren

---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

Re: [HACKERS] How to check the postgresql version

[Joe Conway]

Neil Conway wrote:
Ruey-Lung Hsiao wrote:
  My problem is: I can't find a way to compare strings in C 
preprocessor directive since PG_VERSION is defined as something like 
"7.4.3" or "7.4.6".
You could try using CATALOG_VERSION_NO in src/include/catversion.h as a 
substitute for the version number.
Along those lines, this is what I've been using in PL/R:
#if (CATALOG_VERSION_NO <= 200211021)
#define PG_VERSION_73_COMPAT
#elif (CATALOG_VERSION_NO <= 200310211)
#define PG_VERSION_74_COMPAT
#else
#define PG_VERSION_80_COMPAT
#endif
I wasn't following this thread earlier, but if you need to distinguish 
between, for example, 7.4.3 and 7.4.6, the above won't help. If you just 
need major Postgres version, it works well.

I think it would probably be a good idea to add a PG_VERSION-workalike 
that is more amenable to use with cpp, though.
I agree. As an example, here's how it's done for R:
/*
 * R version is calculated thus:
 *   Maj * 65536 + Minor * 256 + Build * 1
 * So:
 * version 1.8.0 results in:
 *   (1 * 65536) + (8 * 256) + (0 * 1) == 67584
 * version 1.9.0 results in:
 *   (1 * 65536) + (9 * 256) + (0 * 1) == 67840
 */
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] OpenBSD/Sparc status

[Andrew Dunstan]

Stefan Kaltenbrunner said:
> Tom Lane wrote:
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>
>>>Meanwhile, what do we do? Turn off -O in src/template/openbsd for
>>>some/all releases?
>>
>>
>> Certainly not.  This problem is only known to exist in one gcc version
>> for one architecture, and besides it's only affecting (so far as we
>> can tell) one rather inessential contrib module.  I'd say ignore the
>> test failure until Stefan can get a fixed gcc.
>
> FWIW: I got the bug confirmed by Miod Vallat (OpenBSD hacker) on IRC,
> it  looks that at least OpenBSD 3.6-STABLE and OpenBSD-current on
> Sparc64  with the stock system compiler are affected.


I guess my concern is that on Sparc64/OpenBSD-3.6* at least, this bug is
exposed by the seg tests but might well occur elsewhere and bite us in
various unpleasant ways.

I have no idea how many people out there are using this combination. Of
course, even it it's only one (and I suspect that's the right order of
magnitude) we should want to be careful with their data.

cheers

andrew





---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Unicode characters above 0x10000 #2

[John Hansen]

3 times lucky?

Last one broke utf8 G

This one works, Too tired, sorry for the inconvenience..

... John


cvs.diff
Description: cvs.diff

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] OpenBSD/Sparc status

[Stefan Kaltenbrunner]

Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Meanwhile, what do we do? Turn off -O in src/template/openbsd for 
some/all releases?

Certainly not.  This problem is only known to exist in one gcc version
for one architecture, and besides it's only affecting (so far as we can
tell) one rather inessential contrib module.  I'd say ignore the test
failure until Stefan can get a fixed gcc.
FWIW: I got the bug confirmed by Miod Vallat (OpenBSD hacker) on IRC, it 
looks that at least OpenBSD 3.6-STABLE and OpenBSD-current on Sparc64 
with the stock system compiler are affected.

Stefan
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Error handling in plperl and pltcl

[Thomas Hallgren]

Thomas Hallgren wrote
I'm planning to add subtransactions too, but my approach will be to 
use the savepoint functionality already present in the 
java.sql.Connection interface. Perhaps the plpy implementation could 
do something similar. This is what I'm planning to implement:
In Java, safepoints are identified by an interface rather then just by 
a name. I will (invisibly) include both the name of the safepoint and 
the call level in my implementation of that interface. I will also 
have a nested "call context" where I manage safepoints created by the 
executing function. All of this will be completely hidden from the 
function developer. This will make it possible to enforce the 
following rules:

1. A Safepoint lifecycle must be confined to a function call.
2. Safepoints must be rolled back or released by the same function 
that sets them.

Failure to comply with those rules will result in an exception (elog 
ERROR) that will be propagated all the way up.

Would you consider this as safe?
Regards,
Thomas Hallgren
s/safepoint/savepoint/g

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] How to check the postgresql version

[Neil Conway]

Ruey-Lung Hsiao wrote:
  My problem is: I can't find a way to compare strings in C preprocessor 
directive since PG_VERSION is defined as something like "7.4.3" or 
"7.4.6".
You could try using CATALOG_VERSION_NO in src/include/catversion.h as a 
substitute for the version number.

I think it would probably be a good idea to add a PG_VERSION-workalike 
that is more amenable to use with cpp, though.

-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

Re: [HACKERS] Error handling in plperl and pltcl

[Thomas Hallgren]

Tom Lane wrote:
James William Pye <[EMAIL PROTECTED]> writes:
I have been playing with RollbackToSavepoint and ReleaseSavepoint, but
per Neil's comments on IRC and the fact that I have to annoyingly
construct a List containing the savepoint name. I get the feeling that I
am not meant to use them.

You're right.  You can *not* expose those as user-callable operations in
a PL language.  Consider for example what will happen if the user tries
to roll back to a savepoint that was established outside your function
call, or tries to exit the function while still inside a local
savepoint.  You have to enforce strict nesting of functions and
subtransactions; therefore it's a lot easier to present an API that
looks like an exception-block construct (per plpgsql), or that just
hides the whole deal in the SPI calling interface (as I'm proposing for
plperl/pltcl).
There's been some discussion of creating a "stored procedure" language
that would execute outside the database engine, but still on the server
side of the network connection.  In that sort of context it would be
reasonable to let the user do SAVEPOINT/ROLLBACK (or any other SQL
command).  But our existing PLs most definitely execute inside the
engine, and therefore they can't expose facilities that imply arbitrary
changes in the subtransaction state stack.
I'm planning to add subtransactions too, but my approach will be to use 
the savepoint functionality already present in the java.sql.Connection 
interface. Perhaps the plpy implementation could do something similar. 
This is what I'm planning to implement:

In Java, safepoints are identified by an interface rather then just by a 
name. I will (invisibly) include both the name of the safepoint and the 
call level in my implementation of that interface. I will also have a 
nested "call context" where I manage safepoints created by the executing 
function. All of this will be completely hidden from the function 
developer. This will make it possible to enforce the following rules:

1. A Safepoint lifecycle must be confined to a function call.
2. Safepoints must be rolled back or released by the same function that 
sets them.

Failure to comply with those rules will result in an exception (elog 
ERROR) that will be propagated all the way up.

Would you consider this as safe?
Regards,
Thomas Hallgren

---(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] SRF related and other questions

[Katsaros Kwn/nos]

On Sat, 2004-11-20 at 19:56, Joe Conway wrote:
> When returning "setof record", the column definition must exist in the 
> query, and must match what ultimately is returned. This means that 
> whatever logic you use in your application to write the sql statement 
> must be able to derive the appropriate column types. That said, inside 
> your function you have two choices (at least):
> 
>   -- you can directly determine the column definition used in the sql
>  statement, as in dblink_record()
> 
>  /* get the requested return tuple description */
>  tupdesc = CreateTupleDescCopy(rsinfo->expectedDesc);
> 

Actually I use the code of dblink_record() to execute queries on remote
sites! The thing is that I want either to avoid giving the column types
in startup (I don't think this is possible) OR (preferred and possible,
I suppose) to BYPASS this mechanism by providing another tupdesc
"object" referring to the executed query (as I said this NOT always the
query provided on function call). This would be something like:

tupdesc = CreateTupleDescCopy(my_tupdesc);

>   -- you can use the same logic that your application did to derive
>  the column desc and build it yourself, similar to
>  make_crosstab_tupledesc() in contrib/tablefunc
> 

If this query is executed using SPI calls then this function shows
exactly what I need.But what happends if the query is to be executed
using PQexec() like functions, that is in my case a call to a remote db?
In this case, is there any mechanism that could help retrieve the
tupdesc for this query? I may end up providing different results than
those expected from the original query. An idea was to make a
pg_attribute query to fill the Form_pg_attribute array of the my_tupdesc
but I don't think this is enough (what about TupleConstr *constr, and
aggregate results). Another idea was to parse the Query node (available
for the executed query) and fill this array (again what about
TupleConstr *constr?).

> > Second, could you please tell me where in the code an incoming
> > request, from a remote dblink_record() call, is handled? I'm a little
> > lost here  :-)
> I don't understand what you're asking here. Can you elaborate?

This is topic I just started to study so excuse me if I I'm not so
clear:-). What I'm asking is: what is the mechanism that handles
incoming requests (from remote nodes). Which module listens on port 5432
(I think this is it...) for calls from other computers? Which modules
take the incoming query (execute it and) put the results on wire? I just
need a pointer.

Thanks,
Ntinos Katsaros




---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Unicode characters above 0x10000 #2

[John Hansen]

Updated patch, Disregard old one, it broke ucs2.


... John


cvs.diff
Description: cvs.diff

---(end of broadcast)---
TIP 3: 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: [HACKERS] "no snapshot has been set" error

[Tom Lane]

Ruey-Lung Hsiao <[EMAIL PROTECTED]> writes:
> In my X_in() function, I want to access other table to do some 
> bookkeeping stuff. this table keeps track of the number of calls to 
> X_in(). However, while SPI_connect() returns SPI_OK_CONNECT, whenever I 
> execute SPI_exec( "SELECT count FROM XTABLE", 0), postgres stops 
> executing and issues "Error: no snapshot has been set".

Are you sure you've diagnosed this correctly?  AFAICS it's not possible
to get into SPI without having set a snapshot.  Depending on what PG
version you're using (which you did not say, naughty naughty) there are
paths in interactive query entry that might try to execute datatype
input functions before setting the query snapshot.  But I don't believe
it can happen down inside SPI.  I'd be interested to see a complete
counterexample.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Error handling in plperl and pltcl

[Thomas Hallgren]

Tom Lane wrote:
There's an ancient saying "I can make this code arbitrarily fast ...
if it doesn't have to give the right answer".  I think that applies
here.  Fast and unsafe is not how the Postgres project customarily
designs things.
I'm missing something, that's clear. Because I can't see why the PL/Java 
way of doing it is anything but both fast and 100% safe. I agree 100% 
that unsafe is not an option.

I'm arguing that since my design is totally safe, intuitive, and cover 
90% of the use-cases, it is the best one.

Regards,
Thomas Hallgren
PS.
The current design that prevents non-volatile functions from doing 
things with side effects is not very safe ;-) I persist claiming that 
there's a better (and safe) way to handle that.

---(end of broadcast)---
TIP 3: 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: [HACKERS] How to deal with order by, group by, distinct for user-defined types

[Tom Lane]

Ruey-Lung Hsiao <[EMAIL PROTECTED]> writes:
>My question is: how do I find or define ordering operators for my 
> user-defined type?

Create a default btree index operator class for the type.  See
http://developer.postgresql.org/docs/postgres/xindex.html

regards, tom lane

---(end of broadcast)---
TIP 8: explain analyze is your friend