Re: Multiline plpython procedure - Mailing list pgsql-general

On Fri, Jan 21, 2005 at 12:02:09PM +0100, Marco Colombo wrote:
> On Fri, 21 Jan 2005, Greg Stark wrote:
> >I don't think it's reasonable for pg_dump to think about converting
> >data from one language to another. It's important for pg_dump to
> >restore an identical database. Having it start with special case
> >data conversation from one flavour to another seems too dangerous.
>
> Makes no sense. pg_dump already make a lot of conversions: from internal
> representation (which may be platform dependent) to some common format,
> say text. It's just multi-line text which is a hard to deal with, because
> there _no_ single format for it. pg_dump may just choose one format, and
> stick with it. Every dump/restore will work. You may have trouble editing
> a text dump, but that's another matter. BTW, what pg_dump does on windows?
> I mean with -F p. Does it produce a text file with CRNL line seperator?
> What happens if you feed that file to psql on a Unix box?

Ah, but you see, looking at it from your point of view, pg_dump doesn't
interpret text strings. For example, the python script in a function is
a opaque string. Not multiline, nothing. All postgresql does is pass
that block of opaque data to the interpreter for that language. pg_dump
dumps that opaque data into the output, and the CREATE FUNCTION dumps
that opaque data back into the system tables. Postgresql doesn't
understand python any more or less than perl, tcl, R or any other
language.

The argument here is that basically this opaque data has different
meanings for Python on windows and Python on unix. You can't make any
special cases because I can rename plperl.so to plpython.so (or
vice-versa) the opaque data won't be passed to the interpreter that
you'd expect from looking at the definition.

> I'm for defining a format used by PostgreSQL, and force the python parser
> into accepting it on all platforms. That is, let's set the rule that
> python programs to be embedded into PostgreSQL use \n as line termination.

Wouldn't that disadvantage non-unix pl/python users, whose python
functions would have to be converted at run-time to conform to the
local text format. With the extra bummer that the resulting string may
not be the same size either. Remember, postgresql uses the standard
shared library for the language on the platform, it doesn't build its
own.

But sure, preprocessing the source at run-time seems to be the only
realistic solution without a change to the interpreter.

> Think of this: tomorrow we meet people from Mars. One of them really likes
> PostgreSQL, and ports it to their platform. Being a martian platform, it
> uses a different text file format. Line separator there is the first 1000

<snip>

Spurious argument. You're assuming Martians would use ASCII to write
programs without using one of the two defined line-ending characters.
If they were smart they'd simply use a character set which doesn't have
the ambiguity. If they even use 8-bit bytes. An ASCII C compiler won't
compile EBCDIC source code either, but nobody thinks that's
unreasonable, probably because nobody uses EBCDIC anymore :).

No-one is complaining about the use of line-ending characters, they
could have said that you need a semi-colon to seperate "lines". The
problem is that it's *not consistant* across platforms.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.