> This is from an extension module author's point of view. My module will
> reference these two files only:
>
> Makefile.global
> Makefile.shlib
These files possibly include other makefiles.
> I'm not the least interested in how these files are organized internally
Sure.
> If I have a "pg_conf
Tatsuo Ishii wrote:
At least in Japan PHP is much more popular than Python. If we have
plpython in core, I see no reason we do not have plPHP in core at
least from the "popularity" point of view.
Well I don't know anywhere that PHP isn't more popular than Python. The
question I think
i
So, why tie it into the PostgreSQL source tree? Won't it be popular
enough to live on its own, that it has to be distributed as part of the
core?
Honestly, I don't know if it would be popular enough on its own. Now the
plPerlNG that Andrew
and us are working, yes but plPHP? It is nifty, it is
On Tue, 2004-05-18 at 22:21, Brian Hirt wrote:
> there might be another similar bug that was fixed in 7.4.2
This bug is fixed, but it didn't make in 7.4.2, it is in CVS (both 7.4
and HEAD). Please grab pg_autovacuum.c and .h from CVS, if that doesn't
fix it please let me know.
Thanks,
Matthew
Christopher Kings-Lynne wrote:
> I run psql and I get this:
>
> -bash-2.05b$ psql template1
> Welcome to psql 7.5devel, the PostgreSQL interactive terminal.
>
> Type: \copyright for distribution terms
> \h for help with SQL commands
> \? for help with psql commands
> \g o
Marc G. Fournier wrote:
> On Mon, 17 May 2004, Alvaro Herrera Munoz wrote:
>
> > I have some confidence in that I will be able to deliver it maybe the last
> > week of May. I can only hope, however, that it will not be rejected because
> > it's presented too close to feature freeze.
>
> There is
> On Tue, 18 May 2004, Joshua D. Drake wrote:
>
> > Actually plPHP doesn't require the PostgreSQL source tree... you would
> > just have to modify the Make file to point to the right places.
>
> So, why tie it into the PostgreSQL source tree? Won't it be popular
> enough to live on its own, that
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote:
> I have some confidence in that I will be able to deliver it maybe the last
> week of May. I can only hope, however, that it will not be rejected because
> it's presented too close to feature freeze.
There is no such thing as "too close to featur
James William Pye <[EMAIL PROTECTED]> writes:
> I know I can use RegisterExprContextCallback and the RSI's econtext to
> register a callback for SRFs, but this--or similar
> functionality--does not appear to be available for non-SRFs.
Hm? That functionality works for any function, whether it retu
Nikola Milutinovic <[EMAIL PROTECTED]> writes:
> [ about NaN on Tru64 ]
> This compiles on Tru64 4.0D (the compiler swallows it), but fails on
> Tru64 UNIX 5.1B. Both basic CC and DTK Compaq CC break on that file
> complaining on that constant evaluation. The best way to solve it is to
> use sys
On Tue, 18 May 2004, Joshua D. Drake wrote:
> Actually plPHP doesn't require the PostgreSQL source tree... you would
> just have to modify the Make file to point to the right places.
So, why tie it into the PostgreSQL source tree? Won't it be popular
enough to live on its own, that it has to be
On Tue, 18 May 2004, Heikki Linnakangas wrote:
> I'd like to get the patch committed as soon as the 7.6 release cycle
> begins, with whatever limitations it has at that time.
The nice thing of this is that then you have a development cycle for
others to help ... your patch lays down the "this is
I get a similar failure running pg_dumpall and initdb as well.
Chris
Christopher Kings-Lynne wrote:
I run psql and I get this:
-bash-2.05b$ psql template1
Welcome to psql 7.5devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
I run psql and I get this:
-bash-2.05b$ psql template1
Welcome to psql 7.5devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q
On Tuesday 18 May 2004 21:58, Joshua D. Drake wrote:
> > So you then have to build PHP twice, in an RPM build environment. You
> > mean I can't just have the headers installed to build plPHP? So, follow
> > the
> No you need to make sure that PHP is available as a shared lib.
Which requires you
there might be another similar bug that was fixed in 7.4.2
i just doubled checked the 7.4.2 tarball, and it does have this problem.
you might want to double check to see if it's fixed in 7.4.3, or i can
grab cvs and check it if you like.
On May 18, 2004, at 8:06 PM, Bruce Momjian wrote:
I think
I think we already fixed that in 7.4.2. We also have a few bugs still
in 7.4.2 and we need to get those fixed soon and release 7.4.3.
---
Brian Hirt wrote:
> I'm following up on my own email and cross posting to hackers, be
So you then have to build PHP twice, in an RPM build environment. You mean I
can't just have the headers installed to build plPHP? So, follow the
No you need to make sure that PHP is available as a shared lib.
1.) Build PostgreSQL
2.) Build PHP (with PostgreSQL client support)
3.) Build plPHP
I'm following up on my own email and cross posting to hackers, because
there is a bug that needs fixed. I spent some more time digging into
this, and I found the cause of the problem.
reltuples in pg_class is defined as a real, reltuples in pg_autovacuum
is defined as an int. the query
On Tuesday 18 May 2004 17:33, Joshua D. Drake wrote:
> > But most binary packages do, and they are the ones I'm talking about.
> > And surely you do not advocate that, in order to build PL/PHP, the
> > packagers instead disable the client side support in PHP?
> Of course not, but I still don't see
Greg Copeland writes:
> My primary fear about delivering Win32 with all of these other great
> features is that, IMO, there is a higher level of risk associated with
> these advanced features. At the same time, this will be the
> first trial for many Win32 users. Should there be some problems,
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Fabien COELHO wrote:
> >> Neil - can you check your SQL2003 copy to see if it mentions standard
> >> aggregates on bit types?
>
> > I couldn't see any mention of any aggregates specific to the bit types,
>
> There certainly are none,
Seriously though, we all have the roles that we play. I don't think
redirecting specific resources to other
resources will help beyond slowing up the original resources.
And now Neil's on holidays :)
Perhaps we need more committers. The deluge of patches is starting to
strain the major develope
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> What can be done? Well, money from Fujitsu and other companies
> (Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit
> some of these bigger items, so hopefully that will move us forward
> in these complex areas. I am not sure what
Neil Conway <[EMAIL PROTECTED]> writes:
> Fabien COELHO wrote:
>> Neil - can you check your SQL2003 copy to see if it mentions standard
>> aggregates on bit types?
> I couldn't see any mention of any aggregates specific to the bit types,
There certainly are none, since in fact SQL2003 removes th
Peter Eisentraut wrote:
> Tom Lane wrote:
> > > What use could printing the relative path possibly have?
> >
> > Debugging. If I can't see it, I *know* I'm going to wish I could.
>
> Well, you can just look inside, it's not that big. Supporting extra
> options might make the script twice as big
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I guess what you are saying is we should have a configure-time option to
> >> address configured directories via relative paths from the executable's
> >> directory, rather than absolute paths? Seems reasonable ..
Dave Cramer <[EMAIL PROTECTED]> writes:
> While I'm asking how can I find all of the user defined types, assuming
> that the user is the owner of the cluster. I see that pg_dump can do
> this ?
IIRC, what pg_dump actually does is look for types that are not in the
pg_catalog schema. Plus you prob
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Why is the isLocal-parameter false? Couldn't it be true as well? It works
> as it is, since the XactIsoLevel variable is reset to default value in
> StartTransaction anyway, but it looks silly to me to define the variable
> as a session variable when
Bruce Momjian wrote:
Peter Eisentraut wrote:
Jan Wieck wrote:
> Boy, nobody was suggesting 100% static linking. What kind of madness
> are you getting into if you link libpq.a into psql? There is
> something between all or nothing, isn't there?
It's not going to be only psql and libpq. The next th
Peter Eisentraut wrote:
Joshua D. Drake wrote:
Of course not, but I still don't see your point. plPHP doesn't need
PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using
plPHP...
PHP doesn't even need to be installed for plPHP to work... You just
need the source tree for building.
O.
Fabien COELHO wrote:
Any idea? The best I have would be to create a "src" subdir in the
installation, so that top_builddir could be set to
".../include/postgresql/config" and everything would work from that
point of view.
This is from an extension module author's point of view. My module will
refe
Gaetano Mendola wrote:
Currently some changes are back ported to old branches ( BTW, why not to
switch to use "subversion"? ) so I don't think this actualy a big issue
The only changes that are presently backported are bug fixes that the
committing developer feels confident will not cause a regres
Joshua D. Drake wrote:
> Of course not, but I still don't see your point. plPHP doesn't need
> PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using
> plPHP...
>
> PHP doesn't even need to be installed for plPHP to work... You just
> need the source tree for building.
I don't talk ab
Peter Eisentraut wrote:
> Jan Wieck wrote:
> > Boy, nobody was suggesting 100% static linking. What kind of madness
> > are you getting into if you link libpq.a into psql? There is
> > something between all or nothing, isn't there?
>
> It's not going to be only psql and libpq. The next thing is,
Jan Wieck wrote:
> Boy, nobody was suggesting 100% static linking. What kind of madness
> are you getting into if you link libpq.a into psql? There is
> something between all or nothing, isn't there?
It's not going to be only psql and libpq. The next thing is, someone
wants to have a relocatable
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > Bruce Momjian wrote:
> > > > We already have --disable-rpath. Seems we would just need
> > > > something to use the *.a files.
> > >
> > > I think it is perfectly sufficient to say that if you want a
> > > relocatable
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > We already have --disable-rpath. Seems we would just need
> > > something to use the *.a files.
> >
> > I think it is perfectly sufficient to say that if you want a
> > relocatable install, don't use rpath. Static linki
Joshua D. Drake wrote:
> Also PHP does not compile the PostgreSQL support by default.
But most binary packages do, and they are the ones I'm talking about.
And surely you do not advocate that, in order to build PL/PHP, the
packagers instead disable the client side support in PHP?
But most binary packages do, and they are the ones I'm talking about.
And surely you do not advocate that, in order to build PL/PHP, the
packagers instead disable the client side support in PHP?
Of course not, but I still don't see your point. plPHP doesn't need
PHP+PostgreSQL support. Nor does
Neil Conway wrote:
Gaetano Mendola wrote:
I well understand the reason to wait a 7.5 in order to delivery
BIG changes that are requiring a initdb, but I don't understand
why little enhancement can not be delivered in a 7.4.3 ( may be
with a short period with a 7.4.3beta ) like the "vacuum delayed".
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
> We already have --disable-rpath. Seems we would just need something
> to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other
Peter Eisentraut wrote:
Bruce Momjian wrote:
We already have --disable-rpath. Seems we would just need something
to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other kinds
of madness.
Boy,
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > We already have --disable-rpath. Seems we would just need something
> > to use the *.a files.
>
> I think it is perfectly sufficient to say that if you want a relocatable
> install, don't use rpath. Static linking will lead to all other kinds
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > We already have --disable-rpath. Seems we would just need something
> > to use the *.a files.
>
> I think it is perfectly sufficient to say that if you want a relocatable
> install, don't use rpath. Static linking will lead to all other kinds
Bruce Momjian wrote:
> We already have --disable-rpath. Seems we would just need something
> to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other kinds
of madness.
Also, some platforms of
Joshua D. Drake wrote:
> > This is very much different, because the PHP distribution contains
> > the PostgreSQL driver, whereas the other languages do not. So you
> > would have
> >
> > PHP build depends on PostgreSQL
>
> Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL
> support
That is irrelevant. A normal binary package of PHP does build the
PostgreSQL support (which is surely in our interest), so the build
dependency holds.
Then I am afraid I don't understand the actual problem. plPHP does not
create a circular dependency because it doesn't require PHP to have
Pos
> The basic problem is that Pg seeks far too much when performing an index
> scan. I have saved an strace of a backend which is selecting 170,000
> rows from a 240,000,000 row table via index scan. The strace shows
> 134,000 seeks and reads, or almost one seek for every tuple in the
> result set.
This is very much different, because the PHP distribution contains the
PostgreSQL driver, whereas the other languages do not. So you would
have
PHP build depends on PostgreSQL
Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL
support to be built into PHP.
Sincerely,
Joshua D.
Jan Wieck wrote:
If I remore the whole -rpath thing, and remove the two -L options and
the -lpq and -lpgport, and add the libpq.a and libpgport.a explicitly
to the linker call, the psql executable on my Linux box grows from
421761 to 677682 bytes in size. It is still shared linked against
libc,
Marko Karppinen wrote:
> I guess the key thing is that pgFoundry shouldn't be a community
> distinct from the core. The same community standards need to apply
> on both sides of the fence.
Yes, and the best way to achieve that would be to not have anything to
pgfoundry and keep everything in the
Joshua D. Drake wrote:
> >One reason against including plPHP in the core would be that it
> > would create a circular build dependency between the packages
> > postgresql and php. I think we should rather avoid that.
>
> It is no different that the dependency between plPerl and Perl,
> plPython an
Jan Wieck wrote:
> > Static linking of our binaries? Hmmm. Makes sense. We would need a
> > special flag for that. I can add it to the TODO.
> >
> > Seems my testing was flawed because I didn't clean out my hard-coded
> > directory properly. I see now:
> >
> > $ bin/initdb
> > bin/in
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >
> > > You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
> > > environment disables setuid() for security reasons on some platforms. So one
> > > would have to
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> Jan Wieck wrote:
>> > I think if we go for the plan outlined, we will not need a special
>> > configure flag. (People might decide to move the install dir long after
>> > they install it.) By default, everything sits under pgsql as pgsq
Joshua D. Drake wrote:
> >Except you miss one key point here ... if Bruce/Tom/Jan have that sort of
> >time, why aren't they doing it now?
> >
> >
> Well I think you might of missed his point. His point was if he could
> pick their priorities. I would kind
> of agree with Robert except that ther
Greg Stark wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
environment disables setuid() for security reasons on some platforms. So one
would have to wrap every PG related program into equally named shell scripts or
aliase
> [EMAIL PROTECTED] wrote:
>
>> This makes me worried. That's the way we *used* to do things, but the
>> sleazy IP lawyers are looking for anything with which they can create
>> the
>> impression of impropriety. The open source and free projects are ground
>> zero for this crap.
>>
>> We *really* n
Marc G. Fournier wrote:
On Tue, 18 May 2004, Robert Treat wrote:
Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend o
Alvaro Herrera Munoz wrote:
Those are PDFs AFAIR, not easily greppable
Not greppable, but any half-decent PDF viewer should have a "search"
feature that should allow much the same thing. Checking the index is
another way to go, although it is somewhat time-consuming.
I don't have access to an AS
[EMAIL PROTECTED] wrote:
> >> Let's just make sure we keep records of the generic sources of where we
> >> find things. I get *really* scared when I see sentences like "I assume
> >> we
> >> can just look at the source and write our own version bypassing any
> >> license." That is categorically a f
On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote:
> On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
>
> > fact that checkpoints, vacuum runs and pg_dumps bog down their machines
> > to the state where simple queries take several seconds care that much
> > for any Win32 port? Do you
> [EMAIL PROTECTED] wrote:
>> >> >> >We've looked at it before. Apart from anything else I don't think
>> >> >> >its license is compatible with PostgreSQL's.
>> >> >>
>> >> >> Well, people can still use it. We just can't distribute
>> >> it... We can
>> >> >> always link to it.
>> >> >> But unless
On Tue, May 18, 2004 at 12:39:08PM -0400, Neil Conway wrote:
> A copy that claims to "represent an almost indistinuishable delta on the
> actual SQL 2003 database standard" is available online here:
>
> http://www.wiscorp.com/sql/sql_2003_standard.zip
Those are PDFs AFAIR, not easily greppable
[EMAIL PROTECTED] wrote:
> >> >> >We've looked at it before. Apart from anything else I don't think
> >> >> >its license is compatible with PostgreSQL's.
> >> >>
> >> >> Well, people can still use it. We just can't distribute
> >> it... We can
> >> >> always link to it.
> >> >> But unless there is
Gaetano Mendola wrote:
I well understand the reason to wait a 7.5 in order to delivery
BIG changes that are requiring a initdb, but I don't understand
why little enhancement can not be delivered in a 7.4.3 ( may be
with a short period with a 7.4.3beta ) like the "vacuum delayed".
I don't think this
[ Sorry for the latency of my response, Chris -- this got buried in my
inbox... ]
Fabien COELHO wrote:
I don't know where these standards are available online... It seems they
are not available:-(
A copy that claims to "represent an almost indistinuishable delta on the
actual SQL 2003 database s
>> >> >We've looked at it before. Apart from anything else I don't think
>> >> >its license is compatible with PostgreSQL's.
>> >>
>> >> Well, people can still use it. We just can't distribute
>> it... We can
>> >> always link to it.
>> >> But unless there is a GUI tool (actually, unless it shows u
Marc G. Fournier wrote:
> On Tue, 18 May 2004, Robert Treat wrote:
>
> > Just like Bruce has often asked the community how they feel about him
> > balancing his time between things like speaking engagements and patch
> > applications, core developers have a limited amount of time they can
> > spen
Greg Stark wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
>
> > You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
> > environment disables setuid() for security reasons on some platforms. So one
> > would have to wrap every PG related program into equally named shell
Jan Wieck wrote:
> Bruce Momjian wrote:
> > Jan Wieck wrote:
> >> > I think if we go for the plan outlined, we will not need a special
> >> > configure flag. (People might decide to move the install dir long after
> >> > they install it.) By default, everything sits under pgsql as pgsql/bin,
> >>
Hi all,
may be this was already discussed, I'm quite new to postgres
( only 3 years ), I try however.
I seen the debate around the time freeze for 7.5, who say to
wait in order to have more "chance" to have PITR, Win32, 2PC...
and who say that wait a month more will not change nothing.
I well under
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
> fact that checkpoints, vacuum runs and pg_dumps bog down their machines
> to the state where simple queries take several seconds care that much
> for any Win32 port? Do you think it is a good sign for those who have
Yes. I am one su
> >> >We've looked at it before. Apart from anything else I don't think
> >> >its license is compatible with PostgreSQL's.
> >>
> >> Well, people can still use it. We just can't distribute
> it... We can
> >> always link to it.
> >> But unless there is a GUI tool (actually, unless it shows up in
Jan Wieck <[EMAIL PROTECTED]> writes:
> You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
> environment disables setuid() for security reasons on some platforms. So one
> would have to wrap every PG related program into equally named shell scripts or
> aliases to just
> Magnus Hagander wrote:
>> >>If you run NTFS, it's still possible to use arbitrary links.
>> >In the Windows
>> >>world, they are called junctions. Microsoft does not provide
>> >a junction tool
>> >>for some reason (perhaps because it's limited to NTFS). A
>> >good tool, free
>> >>and with source
On Tue, 18 May 2004, Robert Treat wrote:
> Just like Bruce has often asked the community how they feel about him
> balancing his time between things like speaking engagements and patch
> applications, core developers have a limited amount of time they can
> spend on any given development effort. I
On Mon, 2004-05-17 at 19:39, Marc G. Fournier wrote:
> On Mon, 17 May 2004, Mike Mascari wrote:
> > Greg Stark wrote:
> > > Simon Riggs <[EMAIL PROTECTED]> writes:
> > >
> > >>I can't complete by 1 June. Think worse of me if you choose.
> > >
> > ...
> > > So in my perfect world I picture 7.5 freez
Peter Eisentraut wrote:
Joshua D. Drake wrote:
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to think that
(as long as the code was good enough) that we could incorporate
plPHP???
One reason a
a release, etc ...
I'd almost say that time would be better spent on coming up with an
effective upgrade method so that upgrading to new releases is easier ...
Please note that I'm not against the backporting, but do understand the
arguments against it in terms of time and manpower ...
I believ
On Tue, 18 May 2004, Dave Cramer wrote:
> If I do create type testint8 as (i int8) and then select typbasetype
> from pg_type where typname='testint8' the value is 0?
You've created a complex type here, not a domain. See typtype and
typrelid for this case.
create domain testint8 as int8; wi
In tcop/utility.c, the isolation level is set with a call like:
SetPGVariable("transaction_isolation", makeList(item->arg), false)
when a BEGIN SERIALIZABLE etc. call is made.
Why is the isLocal-parameter false? Couldn't it be true as well? It works
as it is, since the XactIsoLevel variable is r
Bruce Momjian wrote:
Jan Wieck wrote:
> I think if we go for the plan outlined, we will not need a special
> configure flag. (People might decide to move the install dir long after
> they install it.) By default, everything sits under pgsql as pgsql/bin,
> pgsql/lib, etc. I can't see how making
Dear Jan,
> Depending on the OS you also need funny things like mkldexport shell
> scripts and the like.
Possibly, yes... I don't know. I really need a list, then it is pretty
easy to update all makefiles.
> I thought we had a consensus of providing a template build environment
> for external m
Marc G. Fournier wrote:
On Sat, 15 May 2004, Bruce Momjian wrote:
Fabien COELHO wrote:
>
> Dear hackers,
>
> I wish to submit a small patch so that server includes and
> all necessary configuration files could be installed *by default*.
>
> The current status is that server includes files are only
I'm trying to implement getUDT for the jdbc driver.
It requires the basetype of a type.
If I do create type testint8 as (i int8) and then select typbasetype
from pg_type where typname='testint8' the value is 0?
While I'm asking how can I find all of the user defined types, assuming
that the user
> > That is the plan ... unless someone knows a reason why they
> can't be
> > built independently of the core?
>
> How about this one: Everything we have moved from the core
> to gborg so far has been a miserable failure. The code is no
> longer maintained, or maintained by three different
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote:
> On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote:
> > Can we try to do the 2PC patch now instead of waiting for subtransactions ?
>
> The last post from Heikki I read said that he discovered some serious
> problems with hi
Marko Karppinen wrote:
I guess the key thing is that pgFoundry shouldn't be a community
distinct from the core. The same community standards need to apply
on both sides of the fence.
[snip]
Thanks Marko, you just wrote exactly what I was concerned about with
"features" rather than "applications" b
Bruce Momjian wrote:
Also, I came upon this gem:
$ echo '\\copy test to stdout' | psql -o /tmp/z test
444
444
444
444
444
Seems 'copy to stdout' also has this split idea of sending \copy output
to a different place from other output.
I guess my big qu
Peter Eisentraut wrote:
How about this one: Everything we have moved from the core to gborg so
far has been a miserable failure. The code is no longer maintained, or
maintained by three different competing groups, the documentation has
disappeared, the portability is no longer taken care of, and
> >If you run NTFS, it's still possible to use arbitrary links. In the Windows
> >world, they are called junctions. Microsoft does not provide a junction tool
> >for some reason (perhaps because it's limited to NTFS). A good tool, free
> >and with source, can be found here
> >http://www.sysinterna
> How about this one: Everything we have moved from the core to gborg so
> far has been a miserable failure. The code is no longer maintained, or
> maintained by three different competing groups, the documentation has
> disappeared, the portability is no longer taken care of, and only the
> b
Joshua D. Drake wrote:
> Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
> replace plPerl, I was talking with Bruce and he seemed to think that
> (as long as the code was good enough) that we could incorporate
> plPHP???
One reason against including plPHP in the core would be
95 matches
Mail list logo
