SEO

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_www...=pgsql-patches

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_www...=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. +

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://mail.postgresql.org/mj/mj_www...=pgsql-patches

"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

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

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

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

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

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/

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

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

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

"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

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

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

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

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

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