Do we really want to migrate plproxy and citext into PG core distribution?

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 integrated: they don't appear to have much
of any code that is tightly tied to backend innards. From a features
point of view, yeah they're cool, but there are scads of cool things
out there. 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 of a cloud
of subprojects around the core, or core will eventually collapse of
its own weight. We have not got the manpower to deal with an
ever-inflating collection of allegedly "core" code. If anything,
we ought to be working to push more stuff out of the core distro so
that we can focus on the functionality that has to be there.

So my feeling is that we should not accept either of these patches.

Now, there is some value in submitting the code for review --- certainly
citext is a whole lot better than it was a few weeks ago. I think it
would be a good idea to be open to reviewing pgfoundry code with the
same standards we'd use if we were going to integrate it. Perhaps
commitfest is not the right venue for that, though, if only because
of the possibility of confusion over what's supposed to happen.

Comments?

regards, tom lane

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 this.

Futher, we would need to come up with some organized way to subject
pgFoundry projects to the same level of general scrutiny which core code
gets. Or at least close.

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 Postgres, but not if it's in an add-in package
which the user can't find binaries for.

So I would argue "maybe" on pl/proxy, but that citext does belong in core.

--Josh Berkus

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
version I maintain for 8.3. The latter copies the str_toloer() code
out of formatting.c from CVS and adds a number of includes in order to
get things to work the same as against HEAD. I could probably work
around this, though, if there was a macro with the version number in it.

> Now, there is some value in submitting the code for review ---
> certainly
> citext is a whole lot better than it was a few weeks ago.

Absolutely. I really appreciate the feedback and comments I've
received. Thank you!

> I think it
> would be a good idea to be open to reviewing pgfoundry code with the
> same standards we'd use if we were going to integrate it. Perhaps
> commitfest is not the right venue for that, though, if only because
> of the possibility of confusion over what's supposed to happen.
>
> Comments?

I think that this is a very good idea. But you might have trouble
motivating people to review code that won't be in core unless it's
managed very diligently. An official extended library distribution, as
Josh suggests, would probably help with this, as it then becomes a
project alongside PostgreSQL that bundles a lot of great add-ons,
rather than just leaving all the add-ons to themselves on pgFoundry.

Best,

David

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 Postgres, but not if
> it's in an add-in package which the user can't find binaries for.
>
> So I would argue "maybe" on pl/proxy, but that citext does belong in
> core.

This is my view, as well. If it was in contrib, it'd go a long way
toward addressing a commonly-requested feature, whereas things are
much more difficult to find on pgFoundry. pgFoundry ain't the CPAN,
alas. Even if users do find it in pgFoundry, the fact that it isn't in
core is more likely to be seen as a red flag at this point. One might
ask, why isn't it in core? What's wrong with it? Why is something that
seems so useful relegated to pgFoundry? What's the usual quality of
code on pgFoundry?

Thanks for your consideration!

Best,

David

Josh Berkus <josh(at)agliodbs(dot)com> 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

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 either project to get integrated: they don't appear to have much
> of any code that is tightly tied to backend innards. From a features
> point of view, yeah they're cool, but there are scads of cool things
> out there. 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.

I think there is a case to say that modules that are sufficiently
popular have a case to be in core.

That's not necessarily a large number, but there might well be a case
for citext at least to be among the number at some stage. Surely a case
insensitive text type has more general use than, say, the seg module.

> We *have to* encourage the development of a cloud
> of subprojects around the core, or core will eventually collapse of
> its own weight. We have not got the manpower to deal with an
> ever-inflating collection of allegedly "core" code. If anything,
> we ought to be working to push more stuff out of the core distro so
> that we can focus on the functionality that has to be there.
>

When we can get the much discussed module infrastructure that will make
more sense. We will still need to keep enough modules to make sure that
the infrastructure is working. In general I feel that the number of
modules we have in core is about right. Maybe a small number should be
pushed out.

> So my feeling is that we should not accept either of these patches.
>
> Now, there is some value in submitting the code for review --- certainly
> citext is a whole lot better than it was a few weeks ago. I think it
> would be a good idea to be open to reviewing pgfoundry code with the
> same standards we'd use if we were going to integrate it. Perhaps
> commitfest is not the right venue for that, though, if only because
> of the possibility of confusion over what's supposed to happen.
>
> Comments?
>
>

If we don't have enough resources to maintain them do we have enough to review them?

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 along with it. Is it an advance to force the
regex_replace "i" flag for such a type? I can imagine cases where I
might want it to sort insensitively, but be able to do case sensitive
regex ops on it. It's not as if the user can't supply the flag. So right
now I don't think citext should be included, because there are still
issues to sort out, if for no other reason.

cheers

andrew

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 is not an infinitely large source tarball?

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

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 along with it. Is it an
> advance to force the regex_replace "i" flag for such a type? I can
> imagine cases where I might want it to sort insensitively, but be
> able to do case sensitive regex ops on it. It's not as if the user
> can't supply the flag. So right now I don't think citext should be
> included, because there are still issues to sort out, if for no
> other reason.

I'm happy to work with folks to get them figured out, but at the end,
there may be some differing opinions. If there's a reference
implementation that could be checked (how does a case-insensitive
collation work in another database?), that would be fine.

You can use the "c" flag to get case-sensitive comparison with the
regex functions, though not with the operators. (Maybe this should be
moved to a separate thread?)

Best,

David

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?

Oh, of course. But one thing at a time. I'm in complete agreement that
what goes into core should be pretty conservative, and that the module
problem should be addressed. But even given that, I think that there
is a strong case to be made that citext should be in contrib.

Best,

David

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 sometimes be hard to find, but surely the answer to
> that is not an infinitely large source tarball?
>
> A
>
I'd have to agree with Andrew here. Making it easy to get extensions
would solve lots of problems.

Dave

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.

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 of a cloud of subprojects around the core, or
> core will eventually collapse of its own weight.

One option might be the Perl approach of having separately developed projects
which are snapshotted at stable points and included in the release. It has the
chance to offer the best of both worlds by offloading development outside of
core but provide users with a perceived "complete" system.

For perl this is important because they want programmers to be able to assume
certain modules are present. For postgres the case is less compelling since
there isn't an interoperability issue.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

On Tue, Jul 22, 2008 at 2:39 PM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 of a cloud of subprojects around the core, or
>> core will eventually collapse of its own weight.
>
> One option might be the Perl approach of having separately developed projects
> which are snapshotted at stable points and included in the release. It has the
> chance to offer the best of both worlds by offloading development outside of
> core but provide users with a perceived "complete" system.

Yeah, but then what happens when the offloaded development/maintenance
doesn't happen? We'd end up pulling the package or having to maintain
it ourselves anyway.

/D

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

"Dave Page" <dpage(at)pgadmin(dot)org> writes:

> On Tue, Jul 22, 2008 at 2:39 PM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>>
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 of a cloud of subprojects around the core, or
>>> core will eventually collapse of its own weight.
>>
>> One option might be the Perl approach of having separately developed projects
>> which are snapshotted at stable points and included in the release. It has the
>> chance to offer the best of both worlds by offloading development outside of
>> core but provide users with a perceived "complete" system.
>
> Yeah, but then what happens when the offloaded development/maintenance
> doesn't happen? We'd end up pulling the package or having to maintain
> it ourselves anyway.

Yeah, it's probably a plan which would work better once there's some solidly
maintained external projects for an extended period of time.

I suppose it's not entirely unlike the history of tsearch.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

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 the extensions can sometimes be hard to find, but surely the
>> answer to that is not an infinitely large source tarball?
>>
>>
> I'd have to agree with Andrew here. Making it easy to get extensions
> would solve lots of problems.

What about starting a secondary team that would review extensions?
Projects on pgfoundry could be identified as reviewed and approved as a
type of recommendation that they are of acceptable quality to use in
production - maybe against certain versions.

What I would see is current core developers teaching a new group of
developers to do the add-on code reviews to a point where they could
continue on by themselves - one or two from core may wish to stay in
this group - with core checking in from time to time to ensure the
quality doesn't slip. Thereby giving some confidence in the use of the
add-ons that get *certified*.

A new add-on would be presented to this group and maybe voted on in one
of the lists (General or Admin?) to get acceptance into the review process.

Anyone interested in starting this?

I do agree that the main code doesn't need to contain every feature that
is available. But we do need to improve the perception of add-ons.
Hardly anyone thinks twice about adding an extension to firefox, perl,
gimp or oscommerce or even drivers to the os, and we need to aim for a
similar thought here.

I do think that having a list of reviewed and approved add-ons that is
easily found on the main site along with release downloads will help
along those lines.

We need to promote that postgresql isn't a one-size-fits-all solution,
it is a solid product that can be customised to suite your needs.

--

Shane Ambler
pgSQL (at) Sheeky (dot) Biz

Get Sheeky @ http://Sheeky.Biz

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 written with
no linkage to core to allow them to be created outside of it.

I agree with your general principles on inclusion of features and also
agree that in this specific case the patches should be rejected. Growing
up outside of core cannot be a reason to exclude new capabilities from
core, but it is probably a reason to reject specific code.

In both these cases, I can see that the capability could be provided in
a different way and benefit from tighter integration.

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.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

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 done, I'm glad to do it.

New patch coming later today, BTW.

Thanks,

David

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 PostgreSQL is our
advanced functionality. If we focus only on core SQL features, there
are few reasons to use us over MySQL, Oracle express, SQL Server, or
Firebird.

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 growing.

If the way to do this is by packaging stuff together but maintaining
separate CVS trees, then ok -- but then we need a plan for how we're
going to do that, rather than just rejecting patches.

The general case aside, I really feel strongly that citext belongs in
core unless we come up with some other means to do case-insensitive
text. It's one of the top 10 newbie questions.

--Josh

Simon Riggs <simon(at)2ndquadrant(dot)com> 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 circular argument. They have had to be written with
> no linkage to core to allow them to be created outside of it.

True, but in the form in which they are currently presented there is no
(technical) reason to integrate them: no new capability would be
provided thereby. Contrast with, say, text search, which we integrated
mainly because we could provide easier configuration and a better
dump/restore experience than the contrib module provided.

> In both these cases, I can see that the capability could be provided in
> a different way and benefit from tighter integration.

Perhaps. I think a lot of the dump/restore issue could be solved
generically if we had better "module" support ... but there's no need
to go over that turf again right now.

In the case of citext, I think an "integrated" solution would involve
some way of creating case-insensitive collations, which would certainly
be cool but it requires a whole lot of infrastructure we don't have yet.
And it wouldn't look even a little bit like the present citext, nor
be upward compatible with it.

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.

An important point here is that acceptance of a feature into core (or
even contrib) puts us on the hook to worry about upward compatibility
for it, maybe not forever but for a long time into the future.
I don't think I want to buy into that for either of these as presently
constituted --- they don't match up with what I think the long-term
goals ought to be in these areas.

regards, tom lane

Josh Berkus <josh(at)agliodbs(dot)com> 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, but I think the best response to that is something CPAN-like
for people to easily get hold of recognized extensions, and next best
(or also) a "kitchen sink" installer package that agglomerates the core
and selected outside projects. There aren't any successful extensible
projects that ignore their own extensibility and put everything
interesting into the core project.

> The general case aside, I really feel strongly that citext belongs in
> core unless we come up with some other means to do case-insensitive
> text. It's one of the top 10 newbie questions.

Maybe. I'd be happier about it if I could see a reasonable upgrade path
from that to a SQL-spec-compliant solution (ie, something collation
based).

regards, tom lane

On Tue, 2008-07-22 at 17:36 -0400, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> 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, but I think the best response to that is something CPAN-like
> for people to easily get hold of recognized extensions, and next best
> (or also) a "kitchen sink" installer package that agglomerates the core
> and selected outside projects. There aren't any successful extensible
> projects that ignore their own extensibility and put everything
> interesting into the core project.

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.

apt-get install postgresql-plproxy
portinstall (I think that is the command) postgresql-plproxy

etc...

makes more sense.

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

"Joshua D. Drake" <jd(at)commandprompt(dot)com> 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
> distributions that have them than some cpan style thing that is going to
> break package dependencies.

Better than CPAN is no problem ;-). My point is just that we should
exploit PG's extensibility rather than assume that everything
interesting must wind up in the core tarball.

> 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
packages in it (yet).

regards, tom lane

On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> 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 no problem ;-). My point is just that we should
> exploit PG's extensibility rather than assume that everything
> interesting must wind up in the core tarball.

Heh, o.k. :)

>
> > 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
> packages in it (yet).

Well that was certainly part of my point. We have
http://www.pgsqlrpms.org/

We also push (a ton) of packages up to EPEL.

I also know that Peter has been working on something similar with SuSE
and Debian.

E.g; in short let's work with respective projects to get these as part
of the repositories.

Joshua D. Drake

>
> regards, tom lane
>
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

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 growing.

Well, minimalistic is a new compliment for me... ;-)

Every time we add code to core, the next patch just got bigger since we
must always include all aspects of the server features.

I want to *increase* the extensibility of Postgres with plugins and
APIs. When you mention what we could learn from MySQL, I would say
introduce pluggable extensibility in more places.

Solving the putting the pieces back together problem is a somewhat
easier problem than trying to maintain a whole spittoon full of (cool)
extensions in core.

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

It's a question of priorities.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

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
> packages in it (yet).

I have about 50 packages there, and I do package many pgfoundry
projects, like plproxy, pgsphere, pgpool, orafce, plpgpsm, table_log,
etc.
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

"Joshua D. Drake" <jd(at)commandprompt(dot)com> 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. We have
> http://www.pgsqlrpms.org/
> ...
> E.g; in short let's work with respective projects to get these as part
> of the repositories.

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. *Especially* code that's not 99.44%+ compatible
with what's in their current releases. To take the example I'm most
closely familiar with: sure I can put the latest and greatest into
Fedora rawhide, but that has approximately zip to do with what people
are running in the field. 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
bumps.

So I think the real-world situation is that we have to make stuff
available to people who want to run something newer/different from what
their chosen distro ships. That means providing our own repo.

Certainly I've got no problem with pushing stuff to the official distros
as fast as we can, but you've got to realize that that's gonna be a slow
process, and necessarily always out of date for any distro version that
is actually popular in the field.

regards, tom lane

On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> 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. We have
> > http://www.pgsqlrpms.org/
> > ...
> > E.g; in short let's work with respective projects to get these as part
> > of the repositories.
>
> 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.

Certainly.

> *Especially* code that's not 99.44%+ compatible
> with what's in their current releases. To take the example I'm most
> closely familiar with: sure I can put the latest and greatest into
> Fedora rawhide, but that has approximately zip to do with what people
> are running in the field.

We could have a quality committee? Something that says, "These 5
packages are considered stable by PGDG". Those go into the various
repositories whether published directly to STABLE (or equiv) or are put
into something like Universe.

> So I think the real-world situation is that we have to make stuff
> available to people who want to run something newer/different from what
> their chosen distro ships. That means providing our own repo.
>

Yes that is what pgsqlrpms is.

> Certainly I've got no problem with pushing stuff to the official distros
> as fast as we can, but you've got to realize that that's gonna be a slow
> process, and necessarily always out of date for any distro version that
> is actually popular in the field.

I should note that my point is about using proper package formats first,
working with distros second. I am under no illusion that we will likely
have to have our own repos (which is one of the reasons we have
pgsqlrpms). The good news is, we have the beginnings of this already for
at least three major distros.

It should be relatively trivial to work with macports, fink and freebsd.
I am sure the Open Solaris group would be more than happy to as well.

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

"Joshua D. Drake" <jd(at)commandprompt(dot)com> 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 committee? Something that says, "These 5
> packages are considered stable by PGDG". Those go into the various
> repositories whether published directly to STABLE (or equiv) or are put
> into something like Universe.

I don't think you got the point: such pronouncements would have exactly
zero influence on Red Hat, or any other distro I'm familiar with.
The *assumption* is that upstream thinks their new release is stable,
else they wouldn't have made it. The distros are in the business of
not believing that, until more proof emerges --- preferably from their
own testing.

I know that this is the mind-set at Red Hat, and I'm pretty sure
SUSE and Debian work the same way.

regards, tom lane

On Wed, 2008-07-23 at 00:01 -0400, Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> 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.

I actually think we are talking past each other. I know how distros
work, all to well frankly. Our repos would be unofficial in the Redhat
eye. My point is, the Red Hat eye is irrelevant for a project like this.
Those who are going to confine themselves to that ideal are a lost cause
(for this project). They will run ancient versions of PostgreSQL and
that's cool because they feel they can trust it.

On the other hand, those who need 8.3 (on RHEL4 for example) can get it,
now -- without breaking compatibility and with RPM.

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

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
> bumps.

Debian and Ubuntu have backport repositories that users can selectively refer
to. SUSE has the openSUSE build service, which serves a similar function.
So for these platforms, the infrastructure is there, and given infinite
packaging hands (which we would need under any scheme, of course), all the
packages in all the necessary versions can be provided through the right
channels (defined as, where a user of the environment would look). So I
don't think having our own repository is a problem or even desirable for
these OS/distributions.

And for Red Hat, we have pgsqlrpms.org, which already covers what you
describe.

-----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 the optimizer already kicks ass
but having Tom review other code is pretty invaluable.

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 by distros. Not to say that everything should get
shoved into core, of course, but there are strong arguments for both sides.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200807231145
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkiHUlgACgkQvJuQZxSWSshURACg2MIfdH0cJOTf75HmuGEzlxo6
OBQAn21sqZ+rBEel1cf2dAIYpoWPHwW5
=Pj7J
-----END PGP SIGNATURE-----

"Greg Sabino Mullane" <greg(at)turnstep(dot)com> 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 by distros. Not to say that everything should get
> shoved into core, of course, but there are strong arguments for both sides.

These are all true statements, of course, but ISTM they should be looked
on as problems to be solved. Pushing stuff into core instead of solving
these problems is not a scalable long-term answer.

regards, tom lane

Tom Lane wrote:
> "Greg Sabino Mullane" <greg(at)turnstep(dot)com> 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 by distros. Not to say that everything should get
>> shoved into core, of course, but there are strong arguments for both sides.
>
> These are all true statements, of course, but ISTM they should be looked
> on as problems to be solved. Pushing stuff into core instead of solving
> these problems is not a scalable long-term answer.

A few random thoughts...

The application that comes to mind first for me when you talk plugins is
Firefox. They make it very easy to browse for plugins and to install,
update, remove them. Their plug-in system also tries to account for
Firefox version and OS platform which we would need to do also.

Perhaps one thing that would help PostgreSQL plug-ins is a nice GUI
plug-in browser and management application. The logical place to add
this IMHO is PGAdmin since it is GUI, already talks to the DB and is
cross platform. I'm not saying a GUI should be required to manage
plug-ins, a fully CLI option should be made available too.

On 7/23/08, Greg Sabino Mullane <greg(at)turnstep(dot)com> 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 for (b), as the optimizer already kicks ass
> but having Tom review other code is pretty invaluable.
>
> 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 by distros. Not to say that everything should get
> shoved into core, of course, but there are strong arguments for both sides.

Agreed.

But PL/Proxy has one additional problem.

First, it's a small & simple clustering solution that plays very well
on Postgres strengths - transparent plan cache in functions, transactional
DDL, etc. It allows significantly higher uptime and query-per-sec than
any "plain sql" solution.

But it has serious weakness - it is not "transparent", user needs to change
it's coding style to function-based one. (This is related to the
small-and-simple property.)

So, for it to be useful, the users need to be aware of it as early in
development as possible. 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. So it needs
to be either in main distro or nearby it.

OTOH, the most serious argument against PL/Proxy merge is that when we
do remote tables/views based on SQL-MED, it's quite natural to extend
that on functions, thus making plproxy redundant.

OTOH^2, there has not been any serious thinking on that direction AFAICS,
except how "dbi-link can push down WHERE clause", This suggests it wont
appear before 2011... Not that its a argument for merge, but maybe
pushing it to an "all-presentable-extensions" package and having proper
review done would be a good idea.

--
marko

-----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 to
have a module or package notion into PostgreSQL and a tool to easily
install existing extensions, which would build on PGXS extension
system to build on the fly code version compatible with current major
PG version :
pg_pkg add-mirror http://packages.postgresql.org/
pg-pkg list [remote | available]
pg_pkg add plproxy prefix citext
pg_pkg install plproxy mydatabase
pg_pkg uninstall [--force] plproxy mydatabase
..

Of course details about PostgreSQL module/package management belongs
to some other thread, I'll try to browse our archives to see where we
are on this point and to propose a summary and some ideas if
necessary. Any reader willing to share good starting points? :)

I think having something to easily manage PostgreSQL modules/packages
(including contribs ones) would change the matter here. If it was easy
to fetch a list of -core reviewed or supported extensions and to
install them on ones databases, having plproxy not included in -core
would be an *easy* decision to make.

Le 23 juil. 08 à 19:54, Marko Kreen a écrit :
> appear before 2011... Not that its a argument for merge, but maybe
> pushing it to an "all-presentable-extensions" package and having
> proper
> review done would be a good idea.

Now, it seems to me we already have a place where to distribute
reviewed code, maintained by non-core hackers and integrated into
distributions and documentation of PostgreSQL: contrib.

Maybe contrib (plans to get a better name ongoing? extra, extension,
anything less remote then current naming) would fit the bill here as a
good compromise?

Sorry to raise unwanted subjects, please do not feed the trolls (in
this thread at least) :)
- --
Dimitri Fontaine

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkiHgCUACgkQlBXRlnbh1blP8ACgmKWAN4PyOSUQdl9hM+vZV0xK
PJYAn1OmTreVxrqjDxsTcjGiNFO/30ok
=SYGB
-----END PGP SIGNATURE-----

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?

On 7/24/08, Peter Eisentraut <peter_e(at)gmx(dot)net> 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 reasoning?

Based on my own behaviour.

--
marko

On Wed, 2008-07-23 at 12:38 -0400, Tom Lane wrote:
> "Greg Sabino Mullane" <greg(at)turnstep(dot)com> 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 by distros. Not to say that everything should get
> > shoved into core, of course, but there are strong arguments for both sides.
>
> These are all true statements, of course, but ISTM they should be looked
> on as problems to be solved. Pushing stuff into core instead of solving
> these problems is not a scalable long-term answer.

And being in core does in no way guarantee reviews and updates if stuff
changes in the backend, as long as regression tests pass - as a proof
take a look at pl/python ugliness. it has not been updated in any major
way since it was first written and so does not make use of any newer
ways of writing PLs.

I am currently working on get this fixed, looking, ironically, much at
pl/proxy code to do so.

I was away from net for last 3 weeks, (climbed mt. Elbrus) but I'll get
my patches brushed up in 2-3 weeks to bring pl/python on par with other
PLs.

OTOH, until we have solid foundation for believing that we can move all
(or at least most) PLs out of core, I'd like pl/proxy to be "in the
core", at least "being in the core CVS" sense.

--------------
Hannu

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 provides extensions to SQL that define foreign-data
wrappers and datalink types to allow SQL to manage external data"), it
is in in no way more than a tiny piece of pl/proxy's possible
functionality.

As I see it, pl/proxy extends postgresql into yet another orthogonally
way of being "extensible", doing it in a well defined, but minimalist
way.

> An important point here is that acceptance of a feature into core (or
> even contrib) puts us on the hook to worry about upward compatibility
> for it, maybe not forever but for a long time into the future.

In some weird way, accepting any bigger piece of code into the "core"
often comes with its maintainer, thus providing scalability in the
maintenance front ;)

At least I'm sure that Marko will carry the main burden of maintaining
pl/proxy - maybe not forever but for a long time into the future.

> I don't think I want to buy into that for either of these as presently
> constituted --- they don't match up with what I think the long-term
> goals ought to be in these areas.

pl/proxy provides one way (often called "Sharding") of achieving
essentially unlimited scalability for a frequently occurring real-world
class of data management problems, while interfering minimally with
postgresql's internals. The "unlimited" part is especially true if
pl/proxy is used together with pg/bouncer.

I'm pretty sure that there is no general golden-bullet solution for
achieving this, and thus I can't see how pl/proxy can conflict with any
"long-term goals" in "these areas", for any value of "these areas".

pl/proxy also has some other possible uses, like doing callbacks in
independent transactions, simple remote calls, simple RO load balancing,
etc.

--------------------------
Hannu

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 no general golden-bullet solution for
> achieving this, and thus I can't see how pl/proxy can conflict with any
> "long-term goals" in "these areas", for any value of "these areas".
>
> pl/proxy also has some other possible uses, like doing callbacks in
> independent transactions, simple remote calls, simple RO load balancing,
> etc.

Hannu,

These are all excellent points but I think the real problem here is:

There is nothing that requires pl/proxy to be in core.

Everyone already agrees pl/proxy is very cool technology for PostgreSQL.

I used to make a lot of arguments about pushing things into core, I was
big fanboy of getting Tsearch2 into core. Looking back and getting older
and wiser (no laughing :P) I realize that its almost kind of silly to
keep pushing this stuff into core.

Lots of people talk about legitimacy of the package or some sort of
artificial endorsement that gets created by being in core. Some of it is
personal, it is a big feeling of pride to have a piece of code accepted
to core. It is also a way to beef up the resume and yes generally a way
to deal with more ignorant hosting shops that won't install external
modules.

However this is not a core problem. It is not a hacker problem. It is
and education and advocacy problem. We don't need pl/proxy in core. What
pl/proxy needs is a solid project of its own, with good documentation,
and community members.

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

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 doesn't move us
> > > toward that goal.
>
> > I'm pretty sure that there is no general golden-bullet solution for
> > achieving this, and thus I can't see how pl/proxy can conflict with any
> > "long-term goals" in "these areas", for any value of "these areas".
> >
> > pl/proxy also has some other possible uses, like doing callbacks in
> > independent transactions, simple remote calls, simple RO load balancing,
> > etc.
>
> Hannu,
>
> 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 be
in core either.

Actually, I think that being an independent language / postgresql
extension tool, pl/proxy is _more_ fit to be in core than external
language adapters.

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 included in core as well.

with some slight restructuring (separation of pl-clue and actrual
cacheing/execution) pl/proxy could serve this space as well

> Everyone already agrees pl/proxy is very cool technology for PostgreSQL.
>
> I used to make a lot of arguments about pushing things into core, I was
> big fanboy of getting Tsearch2 into core. Looking back and getting older
> and wiser (no laughing :P) I realize that its almost kind of silly to
> keep pushing this stuff into core.

Not silly at all.

Tsearch in core seems a wise choice, as well as _some_ implementation of
multiple locales.

> Lots of people talk about legitimacy of the package or some sort of
> artificial endorsement that gets created by being in core. Some of it is
> personal, it is a big feeling of pride to have a piece of code accepted
> to core.

Usually it is also a way of getting the _core_ better/more functional.

> It is also a way to beef up the resume and yes generally a way
> to deal with more ignorant hosting shops that won't install external
> modules.
>
> However this is not a core problem. It is not a hacker problem. It is
> and education and advocacy problem. We don't need pl/proxy in core. What
> pl/proxy needs is a solid project of its own, with good documentation,
> and community members.

As mentioned in another mail, we don't _need_ other pl-s (except maybe
pl/pgsql) to be in core either.

And it is an additional bonus for consultants, if we keep some of the
best parts separate ;)

-----------------
Hannu

PS. Thinking more of it, I don't even understand, what it means for a
PL to be "in core" ;)

Are they are under src/pl just for the reason that there is not
contrib/pl ?

Does pushing something into core give impression of trying to get rid of
the responsibility of managing that piece of code ?

------------------
Hannu

Hannu Krosing <hannu(at)krosing(dot)net> 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 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 third-party library along with a PL. The fact that we have three
is historical, but on the other hand I believe we've seen distinct
issues crop up from each one, so maybe only one isn't enough either.

> Actually, I think that being an independent language / postgresql
> extension tool, pl/proxy is _more_ fit to be in core than external
> language adapters.

It teaches us nothing about connecting to outside code, though.

> 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 included in core as well.

And why do you think the above three don't serve that purpose? Or even
more to the point, how likely is it that an unused "dummy" language
would be well-maintained?

regards, tom lane

On Thu, Jul 24, 2008 at 4:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hannu Krosing <hannu(at)krosing(dot)net> 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 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 third-party library along with a PL. The fact that we have three
> is historical, but on the other hand I believe we've seen distinct
> issues crop up from each one, so maybe only one isn't enough either.

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. The extent to which the feature is useful to a
large number of users (or not) and the extent to which it complicates
maintenance of the code base (or not) seem like much more important
issues.

...Robert

"Robert Haas" <robertmhaas(at)gmail(dot)com> 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 straw man, as no one has suggested such a
policy. Any specific decision of this type is going to involve a
combination of factors, and that's only one.

regards, tom lane

On Thu, Jul 24, 2008 at 2:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hannu Krosing <hannu(at)krosing(dot)net> 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 included in core as well.
>
> And why do you think the above three don't serve that purpose? Or even
> more to the point, how likely is it that an unused "dummy" language
> would be well-maintained?

For whatever it's worth, I'm in the middle of writing a PL
(PL/LOLCODE, specifically), and have found helpful examples of how to
do stuff in PL/pgSQL, PL/Perl, *and* pl/proxy. The examples in the
documentation followed by a bunch of hair pulling while reading
PL/pgSQL were enough to get started, without the benefit of a dummy
language. That's not to say that a dummy language wouldn't be useful,
only that for a coder of my caliber (i.e. Not Terribly Skilled but
Able to Code Myself Out of a Wet Paper Bag) it wasn't necessary.
Because pl/proxy is not in core, I didn't immediately look to it for
examples, but was pointed there by a helpful soul on IRC.

My own opinion is that though there have been several in recent years,
new PLs are written rarely enough that "best practices" don't change a
whole lot. PL/Perl and PL/pgSQL particularly are very well maintained,
and thus demonstrate in most cases a perfectly acceptable way of
writing a PL.

As to whether or not pl/proxy should be in core, I have no particular
opinion. PL/LOLCODE probably should not be. :)

- Josh / eggyknap

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Robert Haas" <robertmhaas(at)gmail(dot)com> 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 straw man, as no one has suggested such a
> policy. Any specific decision of this type is going to involve a
> combination of factors, and that's only one.
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

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 how.

If the installer project wants to use it on Windows they can. Of course
that assumes that it runs on windows (I have no idea if it does).

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

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 other module. This is a non-argument.

If you want to be able to do it without building your own, then you
would need to ask the Windows Installer guys (Dave and Magnus) to
include it - they already include lots of non-core stuff, including at
least one PL, IIRC.

cheers

andrew

> 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 hear how.

Sounds like you just need to get a new row in the standard pg_pltemplate.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Hi.

I tackled with hope temporarily. It seems that some adjustment is still required.
http://winpg.jp/~saito/pg_work/plproxy/
However, windows user desires to use. Of course, it is also me.

Regards,
Hiroshi Saito

From: "Joshua D. Drake" <jd(at)commandprompt(dot)com>

> 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 how.
>
> If the installer project wants to use it on Windows they can. Of course
> that assumes that it runs on windows (I have no idea if it does).

Hiroshi Saito wrote:
> Hi.
>
> I tackled with hope temporarily. It seems that some adjustment is
> still required.
> http://winpg.jp/~saito/pg_work/plproxy/
> However, windows user desires to use. Of course, it is also me.

What is stopping you? Whether or not it works on Windows has (or should
have) nothing to do with whether or not it is in core.

Regarding your patch, the change w.r.t. the CONST token looks a bit odd
- can you explain what you're doing and why?

cheers

andrew

>

Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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 pg_pltemplate was first proposed, we discussed including entries in
its standard contents for all the known non-core PLs. I forget the
arguments that were made against that, but I still think it'd be a good
idea. It'd save one step in installing a non-core PL, and the entries
couldn't cause any harm, since they'd be useless unless the admin had
actually installed the corresponding .so into the installation's
$libdir.

regards, tom lane

> What is stopping you? Whether or not it works on Windows has (or should
> have) nothing to do with whether or not it is in core.

I think that plproxy is great. However, the windows user did not complain.
Because, build was not easy. Therefore, pginstaller has not chosen.
Then, I thought that I wanted to solve....but, I do not have a spare time.
Are they unrelated? I'm sorry if it is a noise....

>
> Regarding your patch, the change w.r.t. the CONST token looks a bit odd
> - can you explain what you're doing and why?

Ad hoc in order to clarify a problem.

Regards,
Hiroshi Saito

Tom Lane wrote:
> Hannu Krosing <hannu(at)krosing(dot)net> 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 third-party library along with a PL. The fact that we have three
> is historical, but on the other hand I believe we've seen distinct
> issues crop up from each one, so maybe only one isn't enough either.

Wouldn't it provide even more benefit if these were maintained
as independent modules *outside* of core but still by the core team.

That would not only help track issues of loading the library as Tom
described; but also issues related to maintaining external modules.

Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> 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 in sync.

regards, tom lane

On 7/25/08, Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> wrote:
> I tackled with hope temporarily. It seems that some adjustment is still
> required.
> http://winpg.jp/~saito/pg_work/plproxy/
> However, windows user desires to use. Of course, it is also me.
> Regards,
> Hiroshi Saito

Thanks, I applied the patch to CVS, with minor changes:
- Use HAVE_SYS_SELECT_H instead of WIN32 for <sys/select.h>
- Do SHLIB_LINK += instead of separate var.

Could you please test the attached patch or CVS HEAD,
whether everything works fine now?

Btw, do not worry about regtest failure in plproxy_many,
this is due to differences in system random() function.
The test should rewritten, although I have not yet decided how...

--
marko

On 7/28/08, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> On 7/25/08, Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> wrote:
> > I tackled with hope temporarily. It seems that some adjustment is still
> > required.
> > http://winpg.jp/~saito/pg_work/plproxy/
> > However, windows user desires to use. Of course, it is also me.
> > Regards,
> > Hiroshi Saito
>
> Thanks, I applied the patch to CVS, with minor changes:
> - Use HAVE_SYS_SELECT_H instead of WIN32 for <sys/select.h>
> - Do SHLIB_LINK += instead of separate var.
>
> Could you please test the attached patch or CVS HEAD,
> whether everything works fine now?

One more change - I replaced __attribute__((dllimport)) with PGDLLIMPORT,
which seems more standard.

--
marko

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 part of core distribution will be first thing
people are going to try out. We wanted to save people losing couple of days
trying out dblink before looking for other alternatives like it happend with
us.
2. Various languages are part of core distribution and pl/proxy by adding
possibility to call remotely procedures created with these languages seems
to be logical extension to PostgreSQL in general. And it makes it essential
for pl/proxy to stay compatible with all the developments in function
calling syntax.
3. And last but not least to make it easier to use for whoever who might
need to do remote procedure calls between PostgreSQL servers.

So i rephrase your question:
Would capability to do remote procedure calls useful addition to PostgreSQL
feature set?

In my experience when organization grows out of one database on one server
remote calls are needed quite soon.

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 and not to mention
hours spent debugging over various layers of applications. It just shows how
hackers have totally different point of view on things from people who are
using the program:) But again i am just a manager and should be lower than
grass in hackers list :)

regards.
Asko
skype: askoja

PS: I am sorry for this reply coming so late didn't want to spoil my
vacation :)

On Mon, Jul 21, 2008 at 10:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 either project to get integrated: they don't appear to have much
> of any code that is tightly tied to backend innards. From a features
> point of view, yeah they're cool, but there are scads of cool things
> out there. 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 of a cloud
> of subprojects around the core, or core will eventually collapse of
> its own weight. We have not got the manpower to deal with an
> ever-inflating collection of allegedly "core" code. If anything,
> we ought to be working to push more stuff out of the core distro so
> that we can focus on the functionality that has to be there.
>
> So my feeling is that we should not accept either of these patches.
>
> Now, there is some value in submitting the code for review --- certainly
> citext is a whole lot better than it was a few weeks ago. I think it
> would be a good idea to be open to reviewing pgfoundry code with the
> same standards we'd use if we were going to integrate it. Perhaps
> commitfest is not the right venue for that, though, if only because
> of the possibility of confusion over what's supposed to happen.
>
> Comments?
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Hi Marko-san.

Great thanks!!
Please correct one mistake of mine...sorry.
This patch solved problem of win32.:-)

Regards,
Hiroshi Saito

----- Original Message -----
From: "Marko Kreen" <markokr(at)gmail(dot)com>

> On 7/28/08, Marko Kreen <markokr(at)gmail(dot)com> wrote:
>> On 7/25/08, Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> wrote:
>> > I tackled with hope temporarily. It seems that some adjustment is still
>> > required.
>> > http://winpg.jp/~saito/pg_work/plproxy/
>> > However, windows user desires to use. Of course, it is also me.
>> > Regards,
>> > Hiroshi Saito
>>
>> Thanks, I applied the patch to CVS, with minor changes:
>> - Use HAVE_SYS_SELECT_H instead of WIN32 for <sys/select.h>
>> - Do SHLIB_LINK += instead of separate var.
>>
>> Could you please test the attached patch or CVS HEAD,
>> whether everything works fine now?
>
> One more change - I replaced __attribute__((dllimport)) with PGDLLIMPORT,
> which seems more standard.
>
> --
> marko
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

On 7/28/08, Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> wrote:
> Please correct one mistake of mine...sorry.
> This patch solved problem of win32.:-)

You mean the += -lws2_32 must be after PGXS? Ok, but moving
the PGXS line is not right as it should after all variables
are set. I moved the SHLIB_LINK += line instead.

Please test.

--
marko

Hi Marko-san.

Thanks! It is comfortable.:-)

Regards,
Hiroshi Saito

----- Original Message -----
From: "Marko Kreen" <markokr(at)gmail(dot)com>

> On 7/28/08, Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> wrote:
>> Please correct one mistake of mine...sorry.
>> This patch solved problem of win32.:-)
>
> You mean the += -lws2_32 must be after PGXS? Ok, but moving
> the PGXS line is not right as it should after all variables
> are set. I moved the SHLIB_LINK += line instead.
>
> Please test.
>
> --
> marko
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

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
> and not to mention hours spent debugging over various layers of
> applications. It just shows how hackers have totally different point
> of view on things from people who are using the program:) But again i
> am just a manager and should be lower than grass in hackers list :)
>
>

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. I think if we adopt that view then we need to
form a plan for doing this right, and soon, as it is a significant
current pain point, especially for people migrating from other databases.

cheers

andrew

On 7/28/08, Asko Oja <ascoja(at)gmail(dot)com> 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 quite easy to extend the implementation to functions:
CREATE REMOTE FUNCTION. Thus making the PL version of remote calls
redundant.

Although that seems a far way off.

Btw, one thing that could be immediately useful would be to extract the
connection defining part from SQL-MED and add that to core, so that dblink,
plproxy and dbi-link could share that. But that needs someone who has
ability to process a 500+ page standard.

--
marko

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 contrib.

> I think if we adopt that view then we need to form a plan for doing
> this right, and soon, as it is a significant current pain point,
> especially for people migrating from other databases.

+1

Best,

David

Andrew Dunstan <andrew(at)dunslane(dot)net> 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 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 conversion would look like, it would assuage
the fear.

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> 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 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 conversion would look like, it would assuage
> the fear.
>
>

I kind of assumed we would do it by implementing the COLLATE clause of
the CREATE DOMAIN statement.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> 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 conversion would look like, it would assuage
>> the fear.

> 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 means "case
insensitive version of whatever the database's default collation is".
This might be worrying over nothing significant, but I'm not
convinced...

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> 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 conversion would look like, it would assuage
>>> the fear.
>>>
>
>
>> 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 means "case
> insensitive version of whatever the database's default collation is".
> This might be worrying over nothing significant, but I'm not
> convinced...
>
>
>

Well, that's all we've got right now.

Presumably as David says we could leave citext sitting in contrib for
compatibility reasons, once we get more fine-grained collation support.

I guess, too, we can add all sorts of warnings about citext not being
future-proof.

cheers

andrew

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 means "case
> insensitive version of whatever the database's default collation is".
> This might be worrying over nothing significant, but I'm not
> convinced...

In the version of COLLATE I did you had variations on locales
(asc/desc, case (in)sensetive) which could be selected. So you could
make COLLATE CASE_INSENSITIVE actually just modify the existing
collation.

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. A database has
no collation, only types, expressions and columns do.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

On Mon, Jul 21, 2008 at 9:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 tables "local"
(importing whole schemas and such). PL/Proxy allows remote calls
and load balancing/distribution. I think it might be even valuable to
use these two together (building on strengths of these two).

By the way, while reading SQL-MED standard I didn't find obvious
way of calling ad-hoc remote tables (as in Oracle's db links for
instance), only either creating remote tables or running in "passthrough"
mode. I guess I did miss something, I was only skimming through it.

As for citext I am less enthusiastic. While I understand the need for
case insensitivity, it feels hacky. Like something which screams to
be more general but fails to do so. And if citext, how about
say rawtext (locale-less text)? [1] utf8text (utf8 compilant text
available even if POSIX localle is used) and so on. ;)

I would still want citext to get into contrib, but my heart is strongest
with PL/Proxy here.

Regards,
Dawid

[1]: Actually I think it would be better to "upgrade" bytea into something
like locale-less, 8-byte, raw-text-alike. I mean, be able to do regex
queries, LIKE queries, etc on it. I sometimes miss that kind of functionality.
--
.................. ``The essence of real creativity is a certain
: *Dawid Kuroczko* : playfulness, a flitting from idea to idea
: qnex42(at)gmail(dot)com : without getting bogged down by fixated demands.''
`..................' Sherkaner Underhill, A Deepness in the Sky, V. Vinge

Martijn van Oosterhout <kleptog(at)svana(dot)org> 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 concept, or a lot
of applications that work fine today will fail.

regards, tom lane

On Jul 28, 2008, at 12:29, Tom Lane wrote:

> Andrew Dunstan <andrew(at)dunslane(dot)net> 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 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 conversion would look like, it would
> assuage
> the fear.

Well, there is no syntax for citext. Right now, lots of folks are
using LOWER() all over the place, in indexes and queries, to get the
behavior implemented by citext, and that will be a *lot* harder to
migrate from than citext will be. 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.

Am I missing something here?

Thanks,

David

"David E. Wheeler" <david(at)kineticode(dot)com> 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 ...

regards, tom lane

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 lc_collate = en_US attempting to
upgrade would then define

CREATE DOMAIN citext AS text COLLATION "en_US(at)ci"

And yes, you would potentially have different definitions of this citext
domain in different database clusters, depending on what configuration you
are upgrading from, but I don't see that as a problem. It is the natural
thing to do.

Peter Eisentraut <peter_e(at)gmx(dot)net> 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".

> So in the future, someone using citext with lc_collate = en_US attempting to
> upgrade would then define
> CREATE DOMAIN citext AS text COLLATION "en_US(at)ci"
> And yes, you would potentially have different definitions of this citext
> domain in different database clusters, depending on what configuration you
> are upgrading from, but I don't see that as a problem. It is the natural
> thing to do.

I'm still not completely convinced that this would be smooth in
practice; for instance there might be situations where you wanted to
define citext but didn't know the target database collation. Still,
I have to concede that it's probably an adequate answer, or at least
close enough that the objection to including citext now doesn't hold up.

It seems that the majority opinion is in favor of including citext
in contrib, so I will go work on that now.

regards, tom lane

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 you mean behavior, in terms of how closely operator
comparisons will return the same results? I have no idea, personally,
but it's no worse then TEXT, is it? The use of TEXT and LOWER() being
what people are doing now?

Best,

David

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
committed anything yet? Shall I pull my improved patch together and
send it today (I was still writing tests and tweaking things to get
the casts right…).

Thanks,

David

"David E. Wheeler" <david(at)kineticode(dot)com> 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.

> Tom, have you committed anything yet?

No, but I've put a couple of hours into editorialization and don't
want to throw that away. How about you wait for my commit and then
send a patch revising whatever you want to?

regards, tom lane

On Jul 29, 2008, at 11:01, Tom Lane wrote:

> "David E. Wheeler" <david(at)kineticode(dot)com> 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.
>
>> Tom, have you committed anything yet?
>
> No, but I've put a couple of hours into editorialization and don't
> want to throw that away. How about you wait for my commit and then
> send a patch revising whatever you want to?

Sure. It's mostly just additional casts and tests. I'd be happy to
integrate it into your commit.

Thanks,

David

"David E. Wheeler" <david(at)kineticode(dot)com> 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 of still having some casting
issues: having to put in a quote_literal(citext) alias function seems
like a huge hack, and I notice that cases like

contrib_regression=# select 'a'::text || 'b'::citext;
ERROR: operator is not unique: text || citext

still don't work even though you put in an alias || operator.

It seems to me that trying to fix these things retail is a losing
proposition. The reason you need these, instead of having everything
"just work" like varchar does, is that citext isn't seen as a member
of the string type category, and so the "preferred type" preference for
text isn't applied. What we ought to do about that IMHO is make a
way for user-defined types to declare what category they belong to.
This has been foreseen as needed for a *very* long time, but we never
really had a forcing function to make us do it before.

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 can't help thinking that that's overkill.

Anyway, debating that is probably material for a separate thread ...

regards, tom lane

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 can't help thinking that that's overkill.
>
> Anyway, debating that is probably material for a separate thread ...

The collation support also needs to determine which data type is text/string.

Zdenek

--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql