Hello Hackers,
I have the following questions, after reading this FAQ (http://
www.postgresql.org/docs/faqs.FAQ.html#item4.4) are there statistics
around the max number of schemas in a database, max number of tables
In a schema, and max number of tables in a database (number that
spans sch
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > How about we remove RELKIND_SPECIAL? It was there only to support
> > the XactLockTable hack, but we don't need that anymore.
>
> Go for it. Don't forget to remove the documentation mentions
> (catalog.sgml at least). Might be a g
COPY wants \r and \n to be used because it checks for line endings, but
your change is only for the SQL strings, and you are right, it is more
porable to dump as actual bytes than backslashes.
---
Tom Lane wrote:
> "Marko Kr
Tom Lane wrote:
> I wrote:
> > Currently looking through the rest of the patch. I'm wondering
> > about appendStringLiteral: maybe we should kill that entirely
> > in favor of using PQescapeStringConn? It's not nearly bright
> > enough about encoding for instance (and it *will* be used in
> > cli
Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking it is best to always use E'' in that case. OK?
>
> I'm planning to revert it to the previous logic: E if there's any
> backslash. I think we have to do likewise in quote_literal() for
> much the same reason: insufficient confidence that
Confirmation: The patch rollback in src/pl/plpgsql/src/gram.y resolved
the issue.
On 5/28/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I wrote:
> Currently looking through the rest of the patch. I'm wondering
> about appendStringLiteral: maybe we should kill that entirely
> in favor of using PQescap
Tom Lane wrote:
"osprey" hasn't been able to build HEAD since the GIN code was added.
I'm not sure that GIN is really to blame though, as the error looks
like an out-of-memory problem while trying to link the backend:
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wendif-la
"osprey" hasn't been able to build HEAD since the GIN code was added.
I'm not sure that GIN is really to blame though, as the error looks
like an out-of-memory problem while trying to link the backend:
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wendif-labels -fno-strict-a
On Sat, May 27, 2006 at 08:23:35PM +0300, Marko Kreen wrote:
> On 5/27/06, Martijn van Oosterhout wrote:
> >Given there is no way to know if you're running single threaded or not,
> >I don't think glibc can take chances like that.
>
> There's CPP symbol _REENTRANT for that and in run time,
> libc
I wrote:
> Currently looking through the rest of the patch. I'm wondering
> about appendStringLiteral: maybe we should kill that entirely
> in favor of using PQescapeStringConn? It's not nearly bright
> enough about encoding for instance (and it *will* be used in
> client-only encodings).
We cou
On Sat, 27 May 2006, Tom Lane wrote:
Michael Fuhr <[EMAIL PROTECTED]> writes:
anoncvs (svr4, 66.98.251.159) is still slow responding to "cvs update";
it's been spotty for about a week now. Tcpdump shows connections being
established but then long delays for ACKs, sometimes long enough for cvs
On Fri, May 26, 2006 at 11:21:32PM -0400, Tom Lane wrote:
> James William Pye <[EMAIL PROTECTED]> writes:
> > So is this "fix your broken PL" or "pg_dump should only be doing that for C
> > language functions"?
>
> Offhand it seems to me that pg_dump is behaving reasonably: it's storing
> probin i
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 5/27/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Historically pg_dump has taken pains to dump ASCII control characters
>> as backslash constructs, for instance \t for tab. I am thinking this
>> is not such a great idea, and that it'd be more portable r
Michael Fuhr <[EMAIL PROTECTED]> writes:
> anoncvs (svr4, 66.98.251.159) is still slow responding to "cvs update";
> it's been spotty for about a week now. Tcpdump shows connections being
> established but then long delays for ACKs, sometimes long enough for cvs
> to time out. Any updates on what
On 5/27/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Historically pg_dump has taken pains to dump ASCII control characters
as backslash constructs, for instance \t for tab. I am thinking this
is not such a great idea, and that it'd be more portable rather than
less so if we got rid of that logic and
Tom Lane wrote:
Historically pg_dump has taken pains to dump ASCII control characters
as backslash constructs, for instance \t for tab. I am thinking this
is not such a great idea, and that it'd be more portable rather than
less so if we got rid of that logic and just dumped tab as tab, etc.
In
Historically pg_dump has taken pains to dump ASCII control characters
as backslash constructs, for instance \t for tab. I am thinking this
is not such a great idea, and that it'd be more portable rather than
less so if we got rid of that logic and just dumped tab as tab, etc.
In particular, making
Any ideas how I can revert back to compilable code?
On 5/28/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Bruce Momjian writes:
> I am thinking it is best to always use E'' in that case. OK?
I'm planning to revert it to the previous logic: E if there's any
backslash. I think we have to do likewise
Bruce Momjian writes:
> I am thinking it is best to always use E'' in that case. OK?
I'm planning to revert it to the previous logic: E if there's any
backslash. I think we have to do likewise in quote_literal() for
much the same reason: insufficient confidence that we know how
the result will
anoncvs (svr4, 66.98.251.159) is still slow responding to "cvs update";
it's been spotty for about a week now. Tcpdump shows connections being
established but then long delays for ACKs, sometimes long enough for cvs
to time out. Any updates on what's going on?
--
Michael Fuhr
-
Tom Lane wrote:
> "Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> > dllwrap -o libplpgsql.dll --dllname libplpgsql.dll --def plpgsql.def
> > pl_gram.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o
> > -L../../../../src/backend -L../../../../src/port -lpostgres
> > Info: resolving _standard_conforming
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> dllwrap -o libplpgsql.dll --dllname libplpgsql.dll --def plpgsql.def
> pl_gram.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o
> -L../../../../src/backend -L../../../../src/port -lpostgres
> Info: resolving _standard_conforming_strings by linking to
> _
Hi All,
I am constantly getting this error:
make -C pl all
make[2]: Entering directory `/d/Dev/postgres/pgsql_tip/src/pl'
make[3]: Entering directory `/d/Dev/postgres/pgsql_tip/src/pl/plpgsql'
make -C src all
make[4]: Entering directory `/d/Dev/postgres/pgsql_tip/src/pl/plpgsql/src'
dlltool -
On 5/27/06, Martijn van Oosterhout wrote:
Given there is no way to know if you're running single threaded or not,
I don't think glibc can take chances like that.
There's CPP symbol _REENTRANT for that and in run time,
libc can detect call to pthread_create [1].
In any case, this isn't the is
On Sat, May 27, 2006 at 06:36:15PM +0300, Marko Kreen wrote:
> >ISTM that in a single-threaded application such as the backend,
> >it should be libc's responsibility to avoid such overhead, not
> >ours.
>
> Obviously, except glibc guys seems to be philosophically
> opposed to this, so apps need to
Martijn van Oosterhout writes:
> How about the suggestion of using a sequential index scan like the
> recent changes to VACUUM in the case that there are no regular index
> quals?
Nonstarter (hint: the solution we found for VACUUM assumes there can
be only one).
regards,
On Sat, May 27, 2006 at 10:57:05AM -0400, Tom Lane wrote:
> * Up to now, the only functions directly invoked by an index AM were
> members of index opclasses; and since opclasses can only be defined by
> superusers, there was at least some basis for trusting the functions
> to behave sanely. But i
On 5/27/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> If you want to use fwrite as string operator, then maybe
> should replace it with fwrite_unlocked?
ISTM that in a single-threaded application such as the backend,
it should be libc's responsibility to avo
Martijn van Oosterhout writes:
> On Fri, May 26, 2006 at 11:38:41AM -0500, Jim C. Nasby wrote:
>> Also, might a bitmap scan be a win for the %string case? Presumably it's
>> much faster to find matching rows via an index and then go back into the
>> heap for them; unless you're matching a heck of
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> If you want to use fwrite as string operator, then maybe
> should replace it with fwrite_unlocked?
ISTM that in a single-threaded application such as the backend,
it should be libc's responsibility to avoid such overhead, not
ours.
Hannu Krosing <[EMAIL PROTECTED]> writes:
> I think we should go on and do promote WITH to a reserved keyword now
> because eventually we have to do it anyway.
> It is needed for recursive queries as well.
I'm unconvinced. Recursive queries have WITH at the front, not the
back, so the parsing iss
Gera Mel Handumon wrote:
Hello,
I'm new to pgsql. I could not find documentation regarding inserting
of picture(.jpg) to BYTEA using Visual Basic (ADO connection). my code
for MSSQL will not work. i'm using pgsql 8.1.4
i also tried this link but an error occur about LO.
http://archives.p
Hello,
I'm new to pgsql. I
could not find documentation regarding inserting of picture(.jpg) to BYTEA
using Visual Basic (ADO connection). my code for MSSQL will not work. i'm using pgsql 8.1.4
i also tried this link but an error occur about LO.
http://archives.postgresql.org/pgsql-odbc/200
Tom Lane wrote:
I wrote:
I'm off for a little visit with oprofile...
It seems the answer is that fwrite() does have pretty significant
per-call overhead, at least on Fedora Core 4. The patch I did yesterday
still ended up making an fwrite() call every few characters when dealing
with bytea
Jim C. Nasby wrote:
Also, regarding needing to place an archiver command in
pg_start_backup_online, another option would be to depend on the
filesystem backup to copy the WAL files, and just let them pile up in
pg_xlog until pg_stop_backup_online. Of course, that would require a
two-step filesy
On 5/27/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I wrote:
> I'm off for a little visit with oprofile...
It seems the answer is that fwrite() does have pretty significant
per-call overhead, at least on Fedora Core 4.
That may be because of the locking ritual all stdio functions
like to do, even
Ühel kenal päeval, R, 2006-05-26 kell 22:50, kirjutas Tom Lane:
> I wrote:
> > We can use the same technique that we used for UNION JOIN, but instead
> > join, say, WITH and TIME into one token and make the time datatype
> > productions look for "TIME WITHTIME ZONE" and so on. (I propose this
> >
37 matches
Mail list logo
