Hi Peter,
:)
All my Pg code is written via (or handed to) an abstraction layer, and
I actually write no functions or stored procedures at all. I write
using Rails, so in this case it's a Ruby library called ActiveRecord
which has a Postgres module that allows me to talk via
"ActiveRecord-speak" or via direct Postgres sql commands. (For example,
AR has no idea how to create a GiST index, so I issue that DDL
statement manually using the special syntax - also AR is not always so
smart about SQL queries so tricky ones I write by hand).
Maybe I misunderstand Q3C completely but it looks like C code that has
to be installed into the Postgres server itself - not a series of SQL
functions that can implemented on an unmodified server. I think my ISP
is fine with anything that gets installed via user-level privileges.
Anything that requires root and/or anything that involves binary code
they are more cautious about.
To be fair, I'm cautious about the same things, but given Oleg's
reputation and contributions to Pg, I wouldn't be so concerned about
Q3C specifically.
Am I ignorant of something fundamental in this conversation? I really
do appreciate any education or insight here. Are C code "patches" or
functions more of a risk to server stability/reliability than higher
level code? Or am I speaking gibberish?
Thanks,
Steve
At 01:01 AM 3/6/2007, Peter Eisentraut wrote:
>Steve Midgley wrote:
> > my ISP that manages my Pg SQL server is (in my interests)
> > concerned about installing anything non-standard (read: unstable)
> > onto their server. I was able to get them to install your TSearch2
> > b/c it's been proven many times, but I'm hesitant to even bring up
> > Q3C since it's less widely deployed.
>
>How do you manage to get your own code installed under that theory?
>
>--
>Peter Eisentraut
>http://developer.postgresql.org/~petere/