actualized SQL/PSM patch

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------

Pavel Stehule wrote:

Hello

I actualized sql/psm patch. This patch can be downloaded from
http://www.pgsql.cz/patches/plpgpsm.diff.gz

Documentation is on wiki http://www.pgsql.cz/index.php/SQL/PSM_Manual

Regards
Pavel Stehule

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your Subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-patches

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

"Pavel Stehule" <pavel.stehule@gmail.com> writes:

I actualized sql/psm patch. This patch can be downloaded from
http://www.pgsql.cz/patches/plpgpsm.diff.gz

The fundamental problem I've got with this patch is that it adds 400K
of new code (and that's just the code, not counting documentation or
regression tests) that we'll have to maintain, to obtain a feature that
so far as I've heard there is precisely zero demand for.

The duplicativeness of the code with plpgsql doesn't make this prospect
any more pleasant, either.

The idea would be a lot easier to swallow if the code were refactored
to avoid the duplication with plpgsql.

regards, tom lane

Hello

On 01/04/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Pavel Stehule" <pavel.stehule@gmail.com> writes:

I actualized sql/psm patch. This patch can be downloaded from
http://www.pgsql.cz/patches/plpgpsm.diff.gz

The fundamental problem I've got with this patch is that it adds 400K
of new code (and that's just the code, not counting documentation or
regression tests) that we'll have to maintain, to obtain a feature that
so far as I've heard there is precisely zero demand for.

The duplicativeness of the code with plpgsql doesn't make this prospect
any more pleasant, either.

The idea would be a lot easier to swallow if the code were refactored
to avoid the duplication with plpgsql.

This is long run and needs hard reorganisation of plpgsql code. And
moving some plpgsql code to core. But I don't expect so plpgpsm code
can be less than 200KB.

Regards
Pavel Stehule

The author has received feedback so this has been saved for the next
commit-fest:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Pavel Stehule wrote:

Hello

On 01/04/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Pavel Stehule" <pavel.stehule@gmail.com> writes:

I actualized sql/psm patch. This patch can be downloaded from
http://www.pgsql.cz/patches/plpgpsm.diff.gz

The fundamental problem I've got with this patch is that it adds 400K
of new code (and that's just the code, not counting documentation or
regression tests) that we'll have to maintain, to obtain a feature that
so far as I've heard there is precisely zero demand for.

The duplicativeness of the code with plpgsql doesn't make this prospect
any more pleasant, either.

The idea would be a lot easier to swallow if the code were refactored
to avoid the duplication with plpgsql.

This is long run and needs hard reorganisation of plpgsql code. And
moving some plpgsql code to core. But I don't expect so plpgpsm code
can be less than 200KB.

Regards
Pavel Stehule

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Apr 1, 2008 at 5:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The fundamental problem I've got with this patch is that it adds 400K
of new code (and that's just the code, not counting documentation or
regression tests) that we'll have to maintain, to obtain a feature that
so far as I've heard there is precisely zero demand for.

We have a customer that wants to use it as part of a MySQL-to-Postgres
migration.

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | http://www.enterprisedb.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 01 Apr 2008 17:55:45 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Pavel Stehule" <pavel.stehule@gmail.com> writes:

I actualized sql/psm patch. This patch can be downloaded from
http://www.pgsql.cz/patches/plpgpsm.diff.gz

The fundamental problem I've got with this patch is that it adds 400K
of new code (and that's just the code, not counting documentation or
regression tests) that we'll have to maintain, to obtain a feature
that so far as I've heard there is precisely zero demand for.

That is likely because everyone knew he was working on it. Consider
this my +1 for pl/psm support.

The duplicativeness of the code with plpgsql doesn't make this
prospect any more pleasant, either.

However, I do agree with you here. I would much prefer it be cleaned up
into its own space.

The idea would be a lot easier to swallow if the code were refactored
to avoid the duplication with plpgsql.

+1.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH9EIYATb/zqfZUUQRAmkiAJ9Q5s2Lsit7lW60sczr1/wxEGX2LACdH2rl
079G3tiL/Jj+B7FU6G5e65c=
=nnba
-----END PGP SIGNATURE-----

Jonah H. Harris wrote:

On Tue, Apr 1, 2008 at 5:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The fundamental problem I've got with this patch is that it adds 400K
of new code (and that's just the code, not counting documentation or
regression tests) that we'll have to maintain, to obtain a feature that
so far as I've heard there is precisely zero demand for.

We have a customer that wants to use it as part of a MySQL-to-Postgres
migration.

Using an implementation like this? I suspect anyone wanting to migrate
their existing SQL/PSM stuff to Postgres will be less than impressed by
our "function body as a string" mechanism.

cheers

andrew

"Joshua D. Drake" <jd@commandprompt.com> writes:

Tom Lane <tgl@sss.pgh.pa.us> wrote:

The fundamental problem I've got with this patch is that it adds 400K
of new code (and that's just the code, not counting documentation or
regression tests) that we'll have to maintain, to obtain a feature
that so far as I've heard there is precisely zero demand for.

That is likely because everyone knew he was working on it.

By "everyone" I suppose you mean the dozen or three people who are
paying close attention to who's doing what in PG development. The
above argument is hogwash, really. If SQL/PSM support were so widely
desired as to justify a code addition of this size, then the archives
would be littered with requests for it. Try to find some. (As a
reasonable comparison point for what it takes to justify a large
code addition, compare that to the number of times that text search
requests show up --- most of them coming from people who don't know
who Oleg and Teodor are.)

I'm not against having SQL/PSM support. I'm just saying I'm not
willing to support two copies of plpgsql to do it.

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 03 Apr 2008 00:57:11 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

Tom Lane <tgl@sss.pgh.pa.us> wrote:

The fundamental problem I've got with this patch is that it adds
400K of new code (and that's just the code, not counting
documentation or regression tests) that we'll have to maintain, to
obtain a feature that so far as I've heard there is precisely zero
demand for.

That is likely because everyone knew he was working on it.

By "everyone" I suppose you mean the dozen or three people who are
paying close attention to who's doing what in PG development.

Well I think that is a bit of an understatement. I know that I have
talked to people about this patch for some time. Even well before 8.3
came out.

I'm not against having SQL/PSM support. I'm just saying I'm not
willing to support two copies of plpgsql to do it.

I didn't disagree with you Tom.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH9GTnATb/zqfZUUQRAlaqAJ0bU/N625e5+BoVQRepETsU4Lij5gCfQ5qo
xOqTAATx8P9AW7ZKE0qAE+I=
=g2v9
-----END PGP SIGNATURE-----

Andrew Dunstan <andrew@dunslane.net> writes:

... I suspect anyone wanting to migrate
their existing SQL/PSM stuff to Postgres will be less than impressed by
our "function body as a string" mechanism.

Yeah, that's the other little problem with claiming standards-compliance
as a reason for doing this. We'd really have to suck it up and figure
some other way of parsing function bodies.

regards, tom lane

Hello

I'm not against having SQL/PSM support. I'm just saying I'm not
willing to support two copies of plpgsql to do it.

regards, tom lane

I understand it well. Pending development of plpgpsm I respected
unbreakability plpgsql. So I can move duplicate parts to separate
files and I'll do it.

I thinking about new directory structure (some like)

pl/sqlsp/ .. sql Stored Procedures
pl/sqlsp/utils
pl/sqlsp/plpgsql - only plpgpsm code
pl/sqlsp/plpgpsm - only plpgsql code

Regards
Pavel Stehule

"Pavel Stehule" <pavel.stehule@gmail.com> writes:

I thinking about new directory structure (some like)

pl/sqlsp/ .. sql Stored Procedures
pl/sqlsp/utils
pl/sqlsp/plpgsql - only plpgpsm code
pl/sqlsp/plpgpsm - only plpgsql code

Maybe "common" instead of "utils"?

Also, where did "plpgpsm" come from? This is supposed to be a standard,
so there is no reason to designate it as PG-specific. plpsm seems the
right name.

regards, tom lane

Andrew Dunstan wrote:

Jonah H. Harris wrote:

On Tue, Apr 1, 2008 at 5:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The fundamental problem I've got with this patch is that it adds 400K
of new code (and that's just the code, not counting documentation or
regression tests) that we'll have to maintain, to obtain a feature that
so far as I've heard there is precisely zero demand for.

We have a customer that wants to use it as part of a MySQL-to-Postgres
migration.

Using an implementation like this? I suspect anyone wanting to migrate
their existing SQL/PSM stuff to Postgres will be less than impressed by
our "function body as a string" mechanism.

What is your point? That because of the $$ strings they might as well
rewrite the whole thing in PL/pgSQL.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

... I suspect anyone wanting to migrate
their existing SQL/PSM stuff to Postgres will be less than impressed by
our "function body as a string" mechanism.

Yeah, that's the other little problem with claiming standards-compliance
as a reason for doing this. We'd really have to suck it up and figure
some other way of parsing function bodies.

Oh, I understand now, that we aren't going to be 100% standards
compliant based on how we quote our function bodies --- I understand
Andrew's point now.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +