2009/3/17 Tom Lane :
> Pavel Stehule 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 init
On Mon, Mar 16, 2009 at 6:20 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
>> 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
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
Bruce Momjian 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.
regards, tom lane
-
Jonah H. Harris wrote:
> On Mon, Mar 16, 2009 at 8:50 PM, Tom Lane wrote:
>
> > Heikki Linnakangas 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 repres
Tom Lane wrote:
> Bruce Momjian 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 tha
Tom Lane wrote:
> Bruce Momjian 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 s
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
wi
Bruce Momjian 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 title contains
Bruce Momjian 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 deadlines ...
>
Tom Lane wrote:
> Heikki Linnakangas 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 deadl
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 c
On Tue, Mar 17, 2009 at 1:16 AM, Jonah H. Harris 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 something else which con
On Mon, Mar 16, 2009 at 8:50 PM, Tom Lane wrote:
> Heikki Linnakangas 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
> indepen
Heikki Linnakangas 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 deadline. We failed to enforce
Pavel Stehule 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.
I'm not sure if the parti
Heikki Linnakangas 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 falls over depending on the line
co
Robert Haas wrote:
> On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
> 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 least o
On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
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 least one more commitfest a
> couple
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
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 expect
Hi,
Le 16 mars 09 à 21:41, Tom Lane a écrit :
Gregory Stark 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 do that.
I think Ope
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 tha
On Mon, Mar 16, 2009 at 04:41:29PM -0400, Tom Lane wrote:
> Gregory Stark 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
> d
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 oth
On Mon, Mar 16, 2009 at 8:41 PM, Tom Lane 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. But I still feel
Gregory Stark 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 going to stop,
because ev
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,
DirectFunct
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.
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
Date: Mon, Mar 9, 2009 at 12:39 PM
Subject: PostgreSQL Memory Management
To: pgsql-gene...@postgresql.org
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%
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 2:34 PM, Tom Lane 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,
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
> wrote:
>
> > 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.
> >
> >
> >
Alvaro Herrera 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 seems like DBI-Link could
On Mon, Mar 16, 2009 at 2:34 PM, Tom Lane 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, there is no way to o
On Mon, Mar 16, 2009 at 2:26 PM, Jonah H. Harris wrote:
> 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
> list.
>
Ahh
Jonah H. Harris escribió:
> On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera
> 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
> list.
Yeah, apparently init_ps_display changes the title inconditionally
Bruce Momjian 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 during backend
Jonah H. Harris wrote:
> On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera
> 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
> list.
I am thinking the title doesn't update _after_ you turn it off, bu
On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera
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
list.
--
Jonah H. Harris, Senior DBA
myYearbook.com
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 parenth
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
On Mon, Mar 16, 2009 at 12:36 PM, Alvaro Herrera 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 parsing the program
name
On Mon, Mar 16, 2009 at 12:50 PM, Tomasz Olszak 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 1:06 PM, Tom Lane 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 since before the e
"Jonah H. Harris" 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 another solution?
Heikki Linnakangas 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 to do.
I'll take this up next.
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 wo
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 que
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
e
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 connect
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, "p
Oleg Bartunov 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 can't really th
On Mon, Mar 16, 2009 at 11:09 AM, Tomasz Olszak 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 this issue.
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 ht
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 variable.
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 p
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 import.ora_a_row
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 experien
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.
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 plpyth
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
> "Ron" == Ron Mayer 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.
Ron> 'a=>1, b=>1'
Simon Riggs 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. Just do it in
>
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-incremen
66 matches
Mail list logo
