Am Monday, 28. July 2008 schrieb Tom Lane:
But to define such a domain, you'd have to commit to a case-insensitive
version of a specific collation, no? citext currently means case
insensitive version of whatever the database's default collation is.
So in the future, someone using citext with
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Monday, 28. July 2008 schrieb Tom Lane:
But to define such a domain, you'd have to commit to a case-insensitive
version of a specific collation, no? citext currently means case
insensitive version of whatever the database's default collation is.
On Jul 28, 2008, at 18:31, Tom Lane wrote:
To upgrade from citext, I expect
that what one will have to do is to alter the column to change its
data type from citext to TEXT + collation.
What I'm wondering is how closely that will match the semantics of the
contrib module ...
By semantics do
On Jul 29, 2008, at 08:58, Tom Lane wrote:
It seems that the majority opinion is in favor of including citext
in contrib, so I will go work on that now.
Damn, I was away from mail yesterday; sorry. I have some revisions,
mostly improving casting compatibility with text. Tom, have you
David E. Wheeler [EMAIL PROTECTED] writes:
Damn, I was away from mail yesterday; sorry. I have some revisions,
mostly improving casting compatibility with text.
Huh? What's to improve?
I know that you're still fooling with the regexp functions, but I
figured that could be added later.
On Jul 29, 2008, at 11:01, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Damn, I was away from mail yesterday; sorry. I have some revisions,
mostly improving casting compatibility with text.
Huh? What's to improve?
I know that you're still fooling with the regexp functions,
David E. Wheeler [EMAIL PROTECTED] writes:
Sure. It's mostly just additional casts and tests. I'd be happy to
integrate it into your commit.
Okay, it's committed with minor revisions --- the biggest thing I fixed
was the lack of an uninstall script.
I saw what you were talking about in terms
Tom Lane napsal(a):
Obviously the solution should involve a new column in pg_type and
a new type property in CREATE TYPE, but what should the representation
be? A full-on approach would make the type categories be real SQL
objects with their own system catalog and reference them by OID,
but I
Hi hackers
Just my non hacker view on the pl/proxy matter.
From FAQ:
PL/Proxy is compact language for remote calls between PostgreSQL databases.
Why we submitted pl/proxy into core at all?
1. Current core distribution contains dblink which sucks both usability wise
and security wise but being
Asko Oja wrote:
About citext. Skype is using various hacks and workarounds because
there was no such type in PostgreSQL and i understand others also. To
me it seems to be choice between couple of developers doing it once
and for all and hundreds of developers inventing the wheel every day
On 7/28/08, Asko Oja [EMAIL PROTECTED] wrote:
Would capability to do remote procedure calls useful addition to PostgreSQL
feature set?
I agree with Tom/Simon on the topic of builtin remote calls - if there
is a plan to implement CREATE REMOTE TABLE/VIEW (builtin remote views)
then it should be
On Jul 28, 2008, at 09:01, Andrew Dunstan wrote:
Plenty of us who are hackers are also users.
ISTM that Tom's objection is really that citext is a hack, and that
it will actually make it harder for us to get to a collation-based
case insensitive comparison.
Well, that's why it's in
Andrew Dunstan [EMAIL PROTECTED] writes:
ISTM that Tom's objection is really that citext is a hack, and that it
will actually make it harder for us to get to a collation-based case
insensitive comparison.
Well, it won't make it harder to implement collations; but I worry that
people who have
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
ISTM that Tom's objection is really that citext is a hack, and that it
will actually make it harder for us to get to a collation-based case
insensitive comparison.
Well, it won't make it harder to implement collations; but I
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, it won't make it harder to implement collations; but I worry that
people who have been relying on the citext syntax will have a hard time
migrating to collations. Perhaps if someone did the legwork to
determine exactly what that
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, it won't make it harder to implement collations; but I worry that
people who have been relying on the citext syntax will have a hard time
migrating to collations. Perhaps if someone did the legwork to
On Mon, Jul 28, 2008 at 03:49:21PM -0400, Tom Lane wrote:
I kind of assumed we would do it by implementing the COLLATE clause of
the CREATE DOMAIN statement.
But to define such a domain, you'd have to commit to a case-insensitive
version of a specific collation, no? citext currently
On Mon, Jul 21, 2008 at 9:43 PM, Tom Lane [EMAIL PROTECTED] wrote:
Comments?
Tough question.
First PL/Proxy. One objection against PL/Proxy is that it might interfere
with SQL-MED implementation. I don't think its the case because both
solve slightly different problems. SQL-MED brings remote
Martijn van Oosterhout [EMAIL PROTECTED] writes:
That said, this is no more of a deal than that text also has a default
collation. You talk about the database's default collation but with
proper collation support that statement is meaningless.
Well, we had better still be able to support the
On Jul 28, 2008, at 12:29, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
ISTM that Tom's objection is really that citext is a hack, and that
it
will actually make it harder for us to get to a collation-based case
insensitive comparison.
Well, it won't make it harder to implement
David E. Wheeler [EMAIL PROTECTED] writes:
To upgrade from citext, I expect
that what one will have to do is to alter the column to change its
data type from citext to TEXT + collation.
What I'm wondering is how closely that will match the semantics of the
contrib module ...
Hi
One of reasons to get PL/proxy into core is to make it available to Windows
users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would like
to hear how.
Asko
On Fri, Jul 25, 2008 at 2:19 AM, Tom Lane [EMAIL
On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote:
Hi
One of reasons to get PL/proxy into core is to make it available to
Windows users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would
like to hear
Asko Oja wrote:
Hi
One of reasons to get PL/proxy into core is to make it available to
Windows users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would
like to hear how.
The same way you would for any
On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote:
One of reasons to get PL/proxy into core is to make it available to
Windows users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would
like to
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote:
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would
like to hear how.
Sounds like you just need to get a new row in the standard pg_pltemplate.
When
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/python to be
in core either.
True, but I think it's a good idea to have at least one such in core,
as a prototype to help us track the issues associated with loading a
large
Ron Mayer [EMAIL PROTECTED] writes:
Wouldn't it provide even more benefit if these were maintained
as independent modules *outside* of core but still by the core team.
This part of the core team isn't willing to do that. I've got enough
work to do without trying to keep multiple repositories
Am Wednesday, 23. July 2008 schrieb Marko Kreen:
And the idea to turn pgfoundry into CPAN
is pointless. An user may willing to throw random modules to his
random perl script, but not to his whole db architecture.
Based on what reasoning?
--
Sent via pgsql-hackers mailing list
On 7/24/08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Wednesday, 23. July 2008 schrieb Marko Kreen:
And the idea to turn pgfoundry into CPAN
is pointless. An user may willing to throw random modules to his
random perl script, but not to his whole db architecture.
Based on what
On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
In the case of plproxy, I think an integrated solution is pronounced
SQL-MED, and likewise plproxy in its present form doesn't move us
toward that goal.
While pl/proxy can be tweaked into a way of achieving functionality of
SQL-MED (SQL/MED
On Thu, 2008-07-24 at 18:38 +0300, Hannu Krosing wrote:
On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
In the case of plproxy, I think an integrated solution is pronounced
SQL-MED, and likewise plproxy in its present form doesn't move us
toward that goal.
I'm pretty sure that there is
On Wed, 2008-07-23 at 12:38 -0400, Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Code outside of core, is, in reality, less reviewed, less likely to work
well with recent PG versions, and more likely to cause problems. It's also
less likely to be found by people, less likely
On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
On Thu, 2008-07-24 at 18:38 +0300, Hannu Krosing wrote:
On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
In the case of plproxy, I think an integrated solution is pronounced
SQL-MED, and likewise plproxy in its present form
Hannu Krosing [EMAIL PROTECTED] writes:
On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
These are all excellent points but I think the real problem here is:
There is nothing that requires pl/proxy to be in core.
AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/python to
On Thu, Jul 24, 2008 at 4:37 PM, Tom Lane [EMAIL PROTECTED] wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
These are all excellent points but I think the real problem here is:
There is nothing that requires pl/proxy to be in core.
Robert Haas [EMAIL PROTECTED] writes:
ISTM that if that if you're willing to admit, even with caveats, that
PL/perl, PL/tcl, or PL/python doesn't need to be in core, then
excluding anything else from core on the basis that it doesn't need to
be there is silly.
You are merely setting up a
On Thu, Jul 24, 2008 at 2:37 PM, Tom Lane [EMAIL PROTECTED] wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
And it would be nice, if some well-maintained sample language (pl/sh or
even pl/dummy) which serves as a sample of latest ways to make use of
pl/function support in core pg code would be
Am Wednesday, 23. July 2008 schrieb Tom Lane:
As soon as a Fedora release happens, I'm
constrained by compatibility issues as to what I can put into that
branch. RHEL releases ten times more so. I gather that Debian, for
instance, is even more paranoid than Red Hat about upstream version
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Do you want Tom to
a) spend a month improving the optimizer
b) get him to review already working code so we can package things
Actually, if the alternative is having the pieces outside of core where
Tom never sees them, I'd vote for (b), as
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Code outside of core, is, in reality, less reviewed, less likely to work
well with recent PG versions, and more likely to cause problems. It's also
less likely to be found by people, less likely to be used by people, and
less likely to be included
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Code outside of core, is, in reality, less reviewed, less likely to work
well with recent PG versions, and more likely to cause problems. It's also
less likely to be found by people, less likely to be used by people, and
less likely
On 7/23/08, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
Do you want Tom to
a) spend a month improving the optimizer
b) get him to review already working code so we can package things
Actually, if the alternative is having the pieces outside of core where
Tom never sees them, I'd vote
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
As a potential user of the solution, I'd very much like to have
plproxy into -core if possible and sensible. Knowing nothing about the
sensible part, I'd vote for inclusion.
But whether -core vote for or against inclusion, I'd appreciate
Am Monday, 21. July 2008 schrieb Tom Lane:
So my feeling is that we should not accept either of these patches.
My feeling as well.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane [EMAIL PROTECTED] writes:
From a project-management point of view, it's insanity to set a presumption
that pgfoundry is just a proving ground for code that should eventually get
into core once it's mature enough or popular enough or whatever. We *have
to* encourage the development
On Tue, Jul 22, 2008 at 2:39 PM, Gregory Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
From a project-management point of view, it's insanity to set a presumption
that pgfoundry is just a proving ground for code that should eventually get
into core once it's mature enough
Dave Page [EMAIL PROTECTED] writes:
On Tue, Jul 22, 2008 at 2:39 PM, Gregory Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
From a project-management point of view, it's insanity to set a presumption
that pgfoundry is just a proving ground for code that should eventually
Dave Cramer wrote:
On 21-Jul-08, at 4:28 PM, Andrew Sullivan wrote:
On Mon, Jul 21, 2008 at 01:17:39PM -0700, David E. Wheeler wrote:
pgFoundry ain't the CPAN, alas.
Maybe that's the problem that really needs solving?
One of the big Postgres features is its extensibility. I agree
that
On Mon, 2008-07-21 at 15:43 -0400, Tom Lane wrote:
From a maintenance point of view there seems little need
for either project to get integrated: they don't appear to have much
of any code that is tightly tied to backend innards.
This is a slightly circular argument. They have had to be
On Jul 22, 2008, at 12:51, Simon Riggs wrote:
I think we should return them with comments that if you integrate them
more with core *and* can justify having done so, then we might include
those features later
I believe I've done both these things for citext, though if there is
more to be
Tom, Simon, etc.:
Of the several things which PostgreSQL could learn from MySQL which we
covered at pgCon was that the requirement to hunt hither and yon for
popular add-ins is one of the primary reasons for developers not using
PostgreSQL.
Further, one of the main reasons why people do use
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-07-21 at 15:43 -0400, Tom Lane wrote:
From a maintenance point of view there seems little need
for either project to get integrated: they don't appear to have much
of any code that is tightly tied to backend innards.
This is a slightly
Josh Berkus [EMAIL PROTECTED] writes:
Tom, Simon, etc.:
Of the several things which PostgreSQL could learn from MySQL which we
covered at pgCon was that the requirement to hunt hither and yon for
popular add-ins is one of the primary reasons for developers not using
PostgreSQL.
Agreed,
On Tue, 2008-07-22 at 17:36 -0400, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Tom, Simon, etc.:
Of the several things which PostgreSQL could learn from MySQL which we
covered at pgCon was that the requirement to hunt hither and yon for
popular add-ins is one of the primary
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 17:36 -0400, Tom Lane wrote:
Agreed, but I think the best response to that is something CPAN-like
for people to easily get hold of recognized extensions,
It seems to me a better solution is to have appropriate repositories for
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
It seems to me a better solution is to have appropriate repositories for
distributions that have them than some cpan style thing that is going to
break package dependencies.
Better than CPAN is
On Tue, 2008-07-22 at 14:06 -0700, Josh Berkus wrote:
Minimalism isn't its own reward. Obviously Tom has reason to worry
about the overall maintenance effort for the PostgreSQL code. But we
need to balance that against the need to add features that users want
and will keep our community
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote:
apt-get install postgresql-plproxy
portinstall (I think that is the command) postgresql-plproxy
I believe Devrim already has a yum repository up and running for
RPM-based distros, though I'm not sure he's got anything but the core
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote:
I believe Devrim already has a yum repository up and running for
RPM-based distros, though I'm not sure he's got anything but the core
packages in it (yet).
Well that was certainly part of my point.
On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote:
I believe Devrim already has a yum repository up and running for
RPM-based distros, though I'm not sure he's got anything but the core
packages
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote:
There's a limit to how far you can go there, because just about any
distro (other than maybe Gentoo) is going to be resistant to dropping in
bleeding-edge versions.
We could have a quality
On Wed, 2008-07-23 at 00:01 -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote:
There's a limit to how far you can go there, because just about any
distro (other than maybe Gentoo) is going to be resistant to dropping in
The current commitfest queue has two entries that propose to migrate
existing pgfoundry projects (or improved versions thereof) into our
core distribution. The more I think about this the less happy I am
with it. From a maintenance point of view there seems little need
for either project to get
Tom,
Comments?
Well, in the *general* case, I think if we're going to have first
class pgfoundry projects, then having a unified official Kitchen Sink
Package will all of these add-ins becomes an imperative priority for
8.4. EDB's recent open sourcing of their installer might help with
On Jul 21, 2008, at 12:43, Tom Lane wrote:
From a maintenance point of view there seems little need
for either project to get integrated: they don't appear to have much
of any code that is tightly tied to backend innards.
Well, citext against CVS HEAD is quite different from the other
On Jul 21, 2008, at 12:53, Josh Berkus wrote:
In the specific cases of pl/proxy and citext, they are very much in
line with what we already package with the core code, including
things like dblink, ISN, and CIDR. citext in particular would
eliminate a long-time newbie complaint about
Josh Berkus [EMAIL PROTECTED] writes:
So I would argue maybe on pl/proxy, but that citext does belong in core.
Well, at least citext is pretty tiny ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Tom Lane wrote:
The current commitfest queue has two entries that propose to migrate
existing pgfoundry projects (or improved versions thereof) into our
core distribution. The more I think about this the less happy I am
with it. From a maintenance point of view there seems little need
for
On Mon, Jul 21, 2008 at 01:17:39PM -0700, David E. Wheeler wrote:
pgFoundry ain't the CPAN, alas.
Maybe that's the problem that really needs solving?
One of the big Postgres features is its extensibility. I agree that
the extensions can sometimes be hard to find, but surely the answer to
that
On Jul 21, 2008, at 13:19, Andrew Dunstan wrote:
I was going to write some stuff about citext anyway. Quite apart
from the above considerations I'm still a bit concerned about its
performance characteristics. And I'm not sure we really want all the
baggage that David is proposing to bring
On Jul 21, 2008, at 13:28, Andrew Sullivan wrote:
Maybe that's the problem that really needs solving?
One of the big Postgres features is its extensibility. I agree that
the extensions can sometimes be hard to find, but surely the answer to
that is not an infinitely large source tarball?
On 21-Jul-08, at 4:28 PM, Andrew Sullivan wrote:
On Mon, Jul 21, 2008 at 01:17:39PM -0700, David E. Wheeler wrote:
pgFoundry ain't the CPAN, alas.
Maybe that's the problem that really needs solving?
One of the big Postgres features is its extensibility. I agree that
the extensions can
73 matches
Mail list logo
