Bruce Momjian wrote:
> I thought about that, but adding additional escape letters isn't our
> problem --- it is the escape mechanism itself that is the issue.
In a random-encoding environment, the option to specify byte values
directly -- at any level -- is of limited value anyway and is a
poten
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Here is an updated version of the COPY \x patch. It is the first patch
> > > attached.
> > > Also, I realized that if we support \x in COPY, we should also support
> > > \x in strings to the backend. This is the second patch.
Has anyone tried to compile postgres with Visual Age compiler on
OpenPower5 (IBM-ese for linux only PowerPC based server) either 32 or 64
bit ?
We got it to build fine on both Suse and RHAS, but have had no luck with
VAC.
I have not researched any deeper,but currently it fails with
[EMAIL PRO
>I have just noticed that this patch:
>
> * Implements a hash-table cache of loaded tables, so we
>don't have
...
>balloons the working store of every backend process by something over 5
>megabytes:
>
>Timezones: 5678768 total in 19 blocks; 3904 free (0 chunks);
>5674864 used
>
>The
On P, 2005-05-29 at 17:19 +0300, Hannu Krosing wrote:
> Has anyone tried to compile postgres with Visual Age compiler on
> OpenPower5 (IBM-ese for linux only PowerPC based server) either 32 or 64
> bit ?
>
> We got it to build fine on both Suse and RHAS, but have had no luck with
> VAC.
That is w
Bruce Momjian writes:
> One other idea would be to remove escape processing for single-quoted
> strings but keep it for our $$ strings, becuase they are not ANSI
> standard.
There is *no* escape processing within $$, and never will be, because
that would destroy the entire point. You'd be right
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Do you agree that using a hashtable for it in general is a good idea
> assuming this sideeffect is removed, though?
I have no problem with the hashtable, only with preloading it with
everything. What I'd like to see is that the table inherited at fo
I'm not sure when this broke, but using contrib/pg_buffercache with
the latest HEAD causes an assertion failure:
test=# SELECT * FROM pg_buffercache;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the reques
Hannu Krosing <[EMAIL PROTECTED]> writes:
> I have not researched any deeper,but currently it fails with
> checking types of arguments for accept()... configure: error: could not
> determine argument types
So look at config.log and see what's going on.
regards, tom lane
For the past couple of releases we've had support for cstring
(null-terminated string) as a full fledged datatype: you set
typlen = -2 to indicate that strlen() must be used to calculate
the actual size of a Datum.
It occurs to me that we should change type UNKNOWN's internal
representation to be
I'm thinking of making two small changes in LockAcquire's behavior:
1. Bogus parameters (in particular an invalid locktable id) should
result in elog(ERROR), not a failure return. The existing API makes
it impossible to tell the difference between an invalid parameter
and an unobtainable lock. T
On Sun, May 29, 2005 at 11:47:18AM -0400, Tom Lane wrote:
> For the past couple of releases we've had support for cstring
> (null-terminated string) as a full fledged datatype: you set
> typlen = -2 to indicate that strlen() must be used to calculate
> the actual size of a Datum.
>
> It occurs to
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I'm not sure when this broke, but using contrib/pg_buffercache with
> the latest HEAD causes an assertion failure:
> test=# SELECT * FROM pg_buffercache;
> server closed the connection unexpectedly
Fixed; turns out to be an ancient parse-analysis bug tha
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Sun, May 29, 2005 at 11:47:18AM -0400, Tom Lane wrote:
>> Anyone see a reason not to change this?
> Is there any way we use UNKNOWN to represent bytea literals?
> Say, comparing a untyped literal to a bytea column?
We use UNKNOWN to represent the ra
Bruce Momjian wrote:
> > I am thinking the only clean solution is to add a special keyword
> > like ESCAPE before strings that contain escape information. I
> > think a GUC is too general. You know if the string is a constant
> > if it contains escapes just by looking at it, and if it is a
> > v
On 2005-05-29, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> On Sun, May 29, 2005 at 11:47:18AM -0400, Tom Lane wrote:
>>> Anyone see a reason not to change this?
>
>> Is there any way we use UNKNOWN to represent bytea literals?
>> Say, comparing a untyped lite
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I do support gradually phasing out backslash escapes in standard string
> literals in the interest of portability. Most of the current escape
> sequences are of limited value anyway. Let's think about ways to get
> there:
I really don't think the
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> Are there any cases where UNKNOWN can be received from the frontend as
> a binary value? I suspect there are.
Sure, but that's transparent because we have binary I/O converters.
You will have trouble if you try to inject an embedded zero that way,
b
On 2005-05-29, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> Are there any cases where UNKNOWN can be received from the frontend as
>> a binary value? I suspect there are.
>
> Sure, but that's transparent because we have binary I/O converters.
> You will ha
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> What happens if you send an UNKNOWN from the frontend as binary, and then
> when the desired type is figured out, it turns out to be a bytea? It's
> obviously not acceptable then to truncate after a zero byte.
This isn't an issue, because if the des
On 2005-05-29, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> What happens if you send an UNKNOWN from the frontend as binary, and then
>> when the desired type is figured out, it turns out to be a bytea? It's
>> obviously not acceptable then to truncate aft
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2005-05-29, Tom Lane <[EMAIL PROTECTED]> wrote:
>> 2. Backend infers actual type of param 1 from context as BYTEA.
> Hrm. I was thinking of the case where the backend can't necessarily do
> this, but in fact in that case the Parse seems to fail.
On Wed, 2005-03-23 at 10:04 -0500, Tom Lane wrote:
> I think last night's discussion makes it crystal-clear why I felt that
> this hasn't been sufficiently thought through. Please revert until the
> discussion comes to a conclusion.
Are there any remaining objections to reapplying this patch?
Th
Neil Conway <[EMAIL PROTECTED]> writes:
> Are there any remaining objections to reapplying this patch?
> The original commit message is here:
> http://archives.postgresql.org/pgsql-committers/2005-03/msg00316.php
> The archives of the -hackers thread are here:
> http://archives.postgresql.org/pgsql
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > > I am thinking the only clean solution is to add a special keyword
> > > like ESCAPE before strings that contain escape information. I
> > > think a GUC is too general. You know if the string is a constant
> > > if it contains escapes just by l
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I do support gradually phasing out backslash escapes in standard string
> > literals in the interest of portability. Most of the current escape
> > sequences are of limited value anyway. Let's think about ways to get
> > there:
I think we can tell people in 8.1 that they should modify their
applications to only use '', and that \' might be a security problem in
the future. If we get to that then using ESC or not only affects input
of values and literal backslashes being entered, and my guess is that
90% of the backslash
Tom Lane wrote:
Fixed; turns out to be an ancient parse-analysis bug that was causing
the view definition to not agree with the function definition if the
function definition included a nondefault typmod.
I wonder though why this contrib module is defining its output as
numeric(10) --- seems li
28 matches
Mail list logo
