Thread: actualized SQL/PSM patch
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
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 > regards, tom lane >
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
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
-----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-----
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. +