On Mon, 2009-03-16 at 10:18 +0800, Xin Wang wrote:
I am using Postgres to build the prototype in a research project. I need
to create a new system catalog table with an auto-increment column. For
a ordinary table, CREATE SEQUENCE or a serial type can be used to
implement the auto-increment
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-03-16 at 10:18 +0800, Xin Wang wrote:
I am using Postgres to build the prototype in a research project. I need
to create a new system catalog table with an auto-increment column.
Other catalog tables use a new oid for each new row/entry.
Ron == Ron Mayer rm...@cheapcomplexdevices.com writes:
Ron Currently hstore gives me an indexed operator to query if a
Ron hstore contains a single key. It'd be nice if there were as way
Ron to extend this so that I could ask for only records that have
Ron all or any the keys in a query.
Teodor Sigaev wrote:
You might want to declare extra_data as just void *, instead of an
array of pointers. The data type implementation might want to store
something there that's not per-key, but applies to the whole query. I
see that you're passing it to comparePartial, but that seems to be
So, I realized that there does not seem to be an easy way for cross
compiling plpython. The configure checks for the locally installed python
include locations and eventually the plpython makefile ends up picking all
the local includes too.
Does anyone have any experiences on cross-compiling
Bruce Momjian wrote:
Well, we have been trying to go simplify the SE-PostgreSQL patch since
September, and while we have made progress, we still have work to do,
and at this point I think we have run out of time. I think we have
given it a fair shot, but I don't think it is going to make 8.4.
Nikhil Sontakke wrote:
So, I realized that there does not seem to be an easy way for cross
compiling plpython. The configure checks for the locally installed
python include locations and eventually the plpython makefile ends up
picking all the local includes too.
Does anyone have any
Greetings to All!
I've tried to find solution of my problem on other pg mailing lists but without
bigger effect.
I have a table A in PG. There is also table A in Oracle.
I want to import specific row from oracle to pg, so i create plperlu function
CREATE OR REPLACE FUNCTION
On Mon, Mar 16, 2009 at 03:16:07PM +0100, Tomasz Olszak wrote:
Greetings to All!
I've tried to find solution of my problem on other pg mailing lists but
without bigger effect.
I have a table A in PG. There is also table A in Oracle.
I want to import specific row from oracle to pg, so
Thank you for quick answer.
I understand, but when I print from plperlu function notices with result of
`env` they're the same in both cases (from remote and local client).
So it looks like that plperlu function is executing from remote and local
clients with the same set of environment
Hi there,
I and Teodor have several small, but useful patches for text search:
1. Support of filtering dictionaries and unaccent dictionary/function.
This is often requested feature, which solves, for example,
problem with correct headlines for text with accents.
See example and docs
On Mon, Mar 16, 2009 at 11:09 AM, Tomasz Olszak tols...@o2.pl wrote:
So it looks like that plperlu function is executing from remote and local
clients with the same set of environment variable.
It has nothing to do with the environment variables.
So I don't have a clue how can I iron out
Oleg Bartunov o...@sai.msu.su writes:
We would like to have your opinion what to do with these patches - leave them
for 8.5 or provide them to hackers to review for 8.4.
In theory 8.5, though you wouldn't be the first to start sneaking in late
commits and given how long before the release I
Jonah H. Harris escribió:
On connection, the Oracle client sends the current application name to the
Oracle server (which is listed in the V$SESSION view); in the case of
Postgres, the program name is the current backend process name text.
Because Oracle picks up Postgres' backend text,
Jonah H. Harris wrote:
Finally, my low-level Oracle knowledge does benefit Postgres :)
:-)
It's a TNS parsing error due to a combination of Oracle's use of a
Lispish s-expression-like name-value pair format and Postgres' process
listing format for remote connections.
On connection,
Ron,
I imagine most EAV systems allow multiple values for each
attribute - and a hstore that supported this could probably
be a pretty nice general solution for many EAV systems. IIRC
other people asked about similar on the lists before.
Well, not usually. Generally, since EAV systems are
Andrew Gierth wrote:
I have a patch almost done that adds some obvious but currently
missing functionality to hstore...
If there's any other features that people find notably missing from
hstore, I could stick them in too; any requests?
Currently hstore gives me an indexed operator to query
Jonah, you're the man :).
Thank you very much, I tried to solve it for about 2 weeks. I know that few
people in the net have the same problem too.
I simply chanche that line, recompile postgresql and wait for some better
solution.
I know that a lot of people uses DBI-LINK. It simply doesn't
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Improve Performance of Multi-Batch Hash Join for Skewed Data Sets
I believe everyone's happy with the performance testing that's been
done. Some of the logic ought to be moved to the planner, and maybe
there's some other cleanup
Jonah H. Harris jonah.har...@gmail.com writes:
The solution to this is to change the following line in
src/backend/postmaster/postmaster.c:
We're not going to break a bunch of other applications in order to make
some undocumented, unsupported Oracle thingie work (until they change
it...). Got
On Mon, Mar 16, 2009 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We're not going to break a bunch of other applications in order to make
some undocumented, unsupported Oracle thingie work (until they change
it...). Got another solution?
Unfortunately, that's the way Oracle has done it
On Mon, Mar 16, 2009 at 12:50 PM, Tomasz Olszak tols...@o2.pl wrote:
Thank you very much, I tried to solve it for about 2 weeks. I know that few
people in the net have the same problem too.
No problem :)
--
Jonah H. Harris, Senior DBA
myYearbook.com
On Mon, Mar 16, 2009 at 12:36 PM, Alvaro Herrera alvhe...@commandprompt.com
wrote:
Jonah H. Harris escribió:
Wow, that's a really idiotic thing for Oracle to do.
Well, being able to find out what applications are connected to the database
is nice. But, it would also be nice if they stopped
All,
Probably somebody should resurrect the Oralink project instead.
http://pgfoundry.org/projects/oralink/
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jonah H. Harris escribió:
I first encountered it while working on database links from PG to Oracle at
EnterpriseDB, and the reason Tomasz couldn't find the answer to this online
is because it's such a rare problem that Oracle has no reason to change it.
Really, how many people have
On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera
alvhe...@commandprompt.comwrote:
We already have one; it's called update_process_title.
I have it turned off, and I still see the remote IP/port in the process
list.
--
Jonah H. Harris, Senior DBA
myYearbook.com
Jonah H. Harris wrote:
On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera
alvhe...@commandprompt.comwrote:
We already have one; it's called update_process_title.
I have it turned off, and I still see the remote IP/port in the process
list.
I am thinking the title doesn't update _after_
Bruce Momjian br...@momjian.us writes:
Jonah H. Harris wrote:
I have it turned off, and I still see the remote IP/port in the process
list.
I am thinking the title doesn't update _after_ you turn it off, but it
was updated when the session started.
Yeah, we intentionally set the title
Jonah H. Harris escribió:
On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera
alvhe...@commandprompt.comwrote:
We already have one; it's called update_process_title.
I have it turned off, and I still see the remote IP/port in the process
list.
Yeah, apparently init_ps_display changes the
On Mon, Mar 16, 2009 at 2:26 PM, Jonah H. Harris jonah.har...@gmail.comwrote:
On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
We already have one; it's called update_process_title.
I have it turned off, and I still see the remote IP/port in the process
On Mon, Mar 16, 2009 at 2:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm finding it hard to believe that there is no way to override what
Oracle's client library does --- there are *plenty* of situations where
you don't really want a client command line exposed to the whole world.
AFAIK,
Alvaro Herrera alvhe...@commandprompt.com writes:
Maybe DBI-Link could set the title to something else before attempting
the connection. (And perhaps locally set update_process_title to off.)
Making the (unwarranted?) assumption that Oracle's library only captures
the title during connect, it
On Mon, Mar 16, 2009 at 02:30:28PM -0400, Jonah H. Harris wrote:
On Mon, Mar 16, 2009 at 2:26 PM, Jonah H. Harris
jonah.har...@gmail.comwrote:
On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
We already have one; it's called update_process_title.
Jonah H. Harris wrote:
On Mon, Mar 16, 2009 at 2:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm finding it hard to believe that there is no way to override what
Oracle's client library does --- there are *plenty* of situations where
you don't really want a client command line exposed to the
On Mon, Mar 16, 2009 at 3:03 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Someone should raise a support request / whatever they call them with
Oracle to get this fixed on their side..
Heh. Why would they fix it when it's only a problem for 1% of their users
in odd
Jonah H. Harris wrote:
On Mon, Mar 16, 2009 at 3:03 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Someone should raise a support request / whatever they call them with
Oracle to get this fixed on their side..
Heh. Why would they fix it when it's only a problem for 1%
Hi,
Please find my original message below. This was originally posted to
pgsql-general, but didn't get any response.
Thanks,
-Umar
-- Forwarded message --
From: Umar Farooq umarf...@gmail.com
Date: Mon, Mar 9, 2009 at 12:39 PM
Subject: PostgreSQL Memory Management
To:
On Mon, Mar 16, 2009 at 3:21 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Because that's what a respectable business does when a customer runs into a
bug with software they sell.
It's not a bug, it's expected behavior. Not that I think it couldn't be
better handled.
Hello
I am playing with custom typmod. I did simple wrapper over varchar type.
PG_FUNCTION_INFO_V1(mvarcharin);
Datum
mvarcharin(PG_FUNCTION_ARGS)
{
elog(NOTICE, %d, PG_GETARG_INT32(2));
return DirectFunctionCall3(varchar,
Gregory Stark st...@enterprisedb.com writes:
I think it's clear that stretching feature freezes is a failed policy.
Yeah, it's the same old same old --- once again, we've bent over
backwards to try to accommodate large patches at the end of a
development cycle. I'm not sure that that's ever
On Mon, Mar 16, 2009 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure that that's ever going to stop,
because every time there are people cheerleading for said patches
and insisting that the release will be so much better if we wait
for them.
Well 8.3 was better for having HOT.
On Mar 16, 2009, at 1:41 PM, Tom Lane wrote:
A saner policy would mandate that large patches land near the start of
a development cycle, but I don't know how we get people to do that.
I think that if you can strictly time-limit the final CommitFest in
the same way that you time-limit the
On Mon, Mar 16, 2009 at 04:41:29PM -0400, Tom Lane wrote:
Gregory Stark st...@enterprisedb.com writes:
I think it's clear that stretching feature freezes is a failed
policy.
Yeah, it's the same old same old --- once again, we've bent over
backwards to try to accommodate large patches at
David E. Wheeler wrote:
On Mar 16, 2009, at 1:41 PM, Tom Lane wrote:
A saner policy would mandate that large patches land near the start of
a development cycle, but I don't know how we get people to do that.
I think that if you can strictly time-limit the final CommitFest in the
same way
Hi,
Le 16 mars 09 à 21:41, Tom Lane a écrit :
Gregory Stark st...@enterprisedb.com writes:
I think it's clear that stretching feature freezes is a failed
policy.
A saner policy would mandate that large patches land near the start of
a development cycle, but I don't know how we get people to
Jonah H. Harris wrote:
On Mon, Mar 16, 2009 at 3:21 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Because that's what a respectable business does when a customer runs into a
bug with software they sell.
It's not a bug, it's expected behavior.
You really call it
On Mon, Mar 16, 2009 at 5:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, I wonder if you could do something malicious with it. Like, run a
query along the lines of SELECT $$ (HOST=10.0.0.123) $$, connect()... to
divert the connection to another server.
Not any
On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The earlier commitfests were not time-limited either. They lasted until all
the patches were dealt with; either committed or bumped to next commit fest.
It's just that when you know there still at
Robert Haas wrote:
On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The earlier commitfests were not time-limited either. They lasted until all
the patches were dealt with; either committed or bumped to next commit fest.
It's just that when you
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, I wonder if you could do something malicious with it.
There are any number of scenarios where exposing the client command-line
contents to other database users represents a security hole, quite
independently of whether anything
Pavel Stehule pavel.steh...@gmail.com writes:
I have a problem - every call of mvarcharin is with typmod = -1.
Sure your typmod_in function works?
Also, there are a bunch of scenarios where we rely on a cast function to
apply the typmod rather than passing it to the input function initially.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
The original plan was that anything not 100% ready to commit at the
beginning of the last commit fest will be bumped to the next release,
and beta would start right after the first commit fest, a week or two
after the submission
On Mon, Mar 16, 2009 at 8:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, I wonder if you could do something malicious with it.
There are any number of scenarios where exposing the client command-line
contents to other database
On Tue, Mar 17, 2009 at 1:16 AM, Jonah H. Harris jonah.har...@gmail.com wrote:
If we want to fix it long-term, we'd have to look at one of the previously
discussed alternatives to using (port).
That's still just a work-around, not a long-term fix. What happens if
the user has parentheses or
That said, I don't see the problem switching to hostname:port. That
seems like a more standard format anyways. It's not a complete
solution to this problem but it does seem like it's less likely to
confuse people and programs, Oracle included. We're getting awfully
conservative about pretty minor
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
The original plan was that anything not 100% ready to commit at the
beginning of the last commit fest will be bumped to the next release,
and beta would start right after the first commit fest, a week or two
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Hot Standby had a different timeline, and quite frankly should have
never been seriously considered for 8.4 at all. But I think that
as long as SEPostgres was looming on the horizon, we didn't see the
point of being strict about
Bruce Momjian br...@momjian.us writes:
I think any serious tools are now using pg_stat_activity. I saw we make
the change in 8.4 and just document it. I wouldn't make the change for
Oracle but rather for clarity.
I think this is a non-solution, because it fails to guarantee that the
process
Hi,
I believe all the issues pointed out in
http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php as
been covered in the current patch, as discussed with Simon. I also
understand that we're running out of time.
I'd like to push this to pgFoundry first and then work again together
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Hot Standby had a different timeline, and quite frankly should have
never been seriously considered for 8.4 at all. But I think that
as long as SEPostgres was looming on the horizon, we didn't see the
point of being
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I think any serious tools are now using pg_stat_activity. I saw we make
the change in 8.4 and just document it. I wouldn't make the change for
Oracle but rather for clarity.
I think this is a non-solution, because it fails to
Jonah H. Harris wrote:
On Mon, Mar 16, 2009 at 8:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, I wonder if you could do something malicious with it.
There are any number of scenarios where exposing the client command-line
Bruce Momjian br...@momjian.us writes:
I was suggesting the colon rather to be clearer, not as an Oracle
fix.
Well, we could certainly debate the change on its own merits, but
I'm not seeing that it's enough nicer to justify a risk of breaking
ps-watching scripts.
I wrote:
Well, we could certainly debate the change on its own merits, but
I'm not seeing that it's enough nicer to justify a risk of breaking
ps-watching scripts.
Also, on second thought: what about IPv6 addresses? Colon doesn't
look like a very good idea at all if you suppose that what's in
On Mon, Mar 16, 2009 at 6:20 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The earlier commitfests were not time-limited either. They lasted until all
the patches were dealt with;
2009/3/17 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I have a problem - every call of mvarcharin is with typmod = -1.
Sure your typmod_in function works?
Also, there are a bunch of scenarios where we rely on a cast function to
apply the typmod rather than
66 matches
Mail list logo
