Boszormenyi Zoltan írta:
> Hi,
>
> my question is that what platform were these
> functions developed and tested?
>
> We have come across a value that fails a NOT NULL
> constraint upon INSERT under HP-UX/IA64, but not
> under x86-64 Linux. The value in question is
> 1.9
Hi,
my question is that what platform were these
functions developed and tested?
We have come across a value that fails a NOT NULL
constraint upon INSERT under HP-UX/IA64, but not
under x86-64 Linux. The value in question is
1.9998 assigned to a "double" variable.
Under HP-UX/IA64, te
Alvaro Herrera írta:
> Boszormenyi Zoltan escribió:
>
>> Alvaro Herrera írta:
>>
>>> I have applied this patch after some tinkering. I mainly added support
>>> for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in
&
Alvaro Herrera írta:
> Boszormenyi Zoltan escribió:
>
>
>> 2) 1b-cursor_name-ctxdiff.patch
>>
>> "name" -> "cursor_name" transition in core grammar
>> and ecpg grammar. Currently it does nothing, it's a
>> preparation phase.
Alvaro Herrera írta:
> Boszormenyi Zoltan escribió:
>
>
>> I have split up (and cleaned up a little) the dynamic
>> cursorname patch into smaller logical, easier-to-review
>> pieces. Descriptions below.
>>
>> 1) 1a-unified-optfromin-fetch-ctxdiff.patch
Hi,
I tried to utilize the advertised feature of 8.4, the
separate fillfactor setting for the toast table.
o=# create table t2 (id serial primary key, t text) with (fillfactor=75,
toast.fillfactor=60);
NOTICE: CREATE TABLE will create implicit sequence "t2_id_seq" for
serial column "t2.id"
ERROR
Hi,
we have come across a problem where we need an inverted index,
an array of IDs ordered by another condition. We came up
with this scheme:
-- final inverted index
CREATE TABLE product.t_product_inv (
wordtextprimary key not null,
ids bigint[]
);
-- transition table
Michael Meskes írta:
> On Wed, Oct 14, 2009 at 06:37:43PM +0200, Boszormenyi Zoltan wrote:
>
>> the attached patch makes ECPG more robust
>> against applications that free() strings by storing
>> its own copy of the prepared statement name.
>>
>
> Ple
Hi,
the attached patch makes ECPG more robust
against applications that free() strings by storing
its own copy of the prepared statement name.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
Michael Meskes írta:
> On Thu, Oct 08, 2009 at 01:15:58PM +0200, Boszormenyi Zoltan wrote:
>
>>> What's the point of that? It can't be applied without documentation,
>>> and it just makes life more complicated to have two separate patch
>>> files fl
Robert Haas írta:
> On Thu, Oct 8, 2009 at 6:22 AM, Boszormenyi Zoltan wrote:
>
>> Noah Misch írta:
>>
>>> I will report on the sqlda patch in more detail on
>>> 2009-10-10.
>>>
>> I am attaching a new one, please review this. Cha
Hi,
thank you very much for the review.
Noah Misch írta:
> I took a look at 2-pg85-sqlda-10-ctxdiff.patch. Starting from CVS HEAD of
> roughly 2009-10-03 05:00 UTC, prerequisite patches 1a-1h applied cleanly.
> 2-pg85-sqlda hit a trivial whitespace reject in ecpg.trailer along with a more
> subs
Robert Haas írta:
> On Fri, Oct 2, 2009 at 9:01 PM, Boszormenyi Zoltan wrote:
>
>> Hi,
>>
>> Michael Meskes írta:
>>
>>> It is accepted either way. I was just pointing out that it might be easier
>>> to
>>> review/com
Michael Meskes írta:
> On Thu, Oct 01, 2009 at 09:05:55PM +0200, Boszormenyi Zoltan wrote:
>
>> Yes, but technical problems and solutions do. ECPG claims
>> to be ESQL/C compatible, but at places it's only half compatible.
>>
>
> Where does it claim to
Michael Meskes írta:
> On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote:
>
>> Please, accept my apologies, I only tried to express my
>> frustration, this is not a good situation for either of us.
>>
>
> Apologies accepted, email is a di
Michael Meskes írta:
> On Thu, Oct 01, 2009 at 03:47:07PM +0200, Boszormenyi Zoltan wrote:
>
>> You're not being fair with me. The dependencies are quite
>> technical.
>>
>
> I'm sorry that you interpreted my email this way, it wasn't at all m
Michael Meskes írta:
> On Wed, Sep 30, 2009 at 12:34:23PM -0400, Tom Lane wrote:
>
>> qualified to review them. (I don't actually think we have anybody
>> except Michael who's really familiar with ecpg.)
>>
>
> I'm afraid I'm simply not able to spend much time on this in the near future
>
Jeff Janes írta:
> On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan <mailto:z...@cybertec.at>> wrote:
>
> Boszormenyi Zoltan írta:
> > Alvaro Herrera írta:
> >
> >> Boszormenyi Zoltan wrote:
> >>
> >>
> >
Jeff Janes írta:
> On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan <mailto:z...@cybertec.at>> wrote:
>
> Boszormenyi Zoltan írta:
> >
> > Okay, we implemented only the lock_timeout GUC.
> > Patch attached, hopefully in an acceptable form.
&
New patch - two decimal-related memory leak fixes.
Happens on 8.4 and 8.5, maybe on older trees as well.
One of the two chunks was in the SQLDA patch originally.
This is independent from any other patches.
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay,
Hi,
I saw the editor added this line:
"Zoltan Boszormenyi sent in a small patch to fix a typo in an earlier
ECPG patch he sent."
This typo fix is an upstream bugfix.
Thanks.
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
th
New patch, typo fix in pgc.l.
According to our customer who is porting their application
to PostgreSQL, this causes an error currently in ECPG:
1. within included structures the use of "$else;" is causing an
precompiler error (tested several times in d
Tom Lane írta:
> Josh Berkus writes:
>
I have a client who uses temp tables heavily, hundreds of thousands of
creates
and drops per day. They also have long running queries. The only
thing that
keeps catalog bloat somewhat in check is vacuum full on bloated catalogs
>>>
Boszormenyi Zoltan írta:
> Alvaro Herrera írta:
>
>> Boszormenyi Zoltan wrote:
>>
>>
>>
>>> The vague consensus for syntax options was that the GUC
>>> 'lock_timeout' and WAIT [N] extension (wherever NOWAIT
>>> is all
Hi,
we have updated our patchset to current 8.5 CVS.
The actual patches will be in emails coming as
answers to this one. As two patches were already included,
the remaining patches are as follows:
1. dynamic cursorname
2. sqlda support
3. describe support
4. proper out-of-scope declare/open/fetch
Bruce Momjian írta:
> Greg Sabino Mullane wrote:
> [ There is text before PGP section. ]
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>> Just noticed in the release notes for 8.4, there are two items
>> accredited to just "Greg" (but there are three of us Gregs who
>> contribute
Heikki Linnakangas írta:
> Boszormenyi Zoltan wrote:
>
>> we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested)
>> while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9.
>>
>> The following defines were used before running config
Tom Lane írta:
> Greg Stark writes:
>
>> Actually it always bothered me that we don't have implicit casts from
>> integer->boolean. I can't see any ambiguity or unintentional effects
>> this would cause problems with. Am I missing something?
>>
>
> Personally, as an old Pascal-lover, I alw
Hi,
we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested)
while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9.
The following defines were used before running configure:
export CFLAGS="-m32"
export LD="ld -melf_i386"
The above are needed because when SUBSYS.o files ar
Michael Meskes írta:
> On Fri, Aug 14, 2009 at 10:12:24PM +0200, Boszormenyi Zoltan wrote:
>
>> Will add the ecpg_log(). What the code does is:
>> - sets up a minimal SQLDA on the first call (called with NULL ptr),
>> so the field types and field names and some other
Michael Meskes írta:
> On Mon, Aug 03, 2009 at 06:12:43PM +0200, Boszormenyi Zoltan wrote:
>
>> - sqlda support:
>> - sqlda.c now indicates license
>> - #defines inside #if 0 ... #endif are now omitted from sqltypes.h
>> (both per comments from Jaime Casanov
Michael Meskes írta:
> On Fri, Aug 14, 2009 at 01:02:07PM +0200, Boszormenyi Zoltan wrote:
>
>> Here are the two test files, with their preprocessed C output.
>> Indeed, Informix emits a function call for DECLARE CURSOR.
>> And it seems it's not legal to
Michael Meskes írta:
> On Thu, Aug 13, 2009 at 05:55:53PM +0200, Boszormenyi Zoltan wrote:
>
>> Okay, so it's a declarative command. But if we're in a function,
>> we should still emit a call to ecpg_init, to be able to follow
>>
>
> No, either it
Michael Meskes írta:
> On Wed, Aug 12, 2009 at 07:13:44PM +0200, Boszormenyi Zoltan wrote:
>
>> a customer of us complained a behavioural difference
>> ...
>> The attached patch implements this. The only downside
>> is that now DECLARE CURSOR cannot appear outside
Hi,
a customer of us complained a behavioural difference
between ESQL/C and ECPG. They check sqlca.sqlcode
almost everywhere in their application currently under
porting to PostgreSQL. Somewhere in their code
however there was a place where a statement error
was ignored and the error was reported
Boszormenyi Zoltan írta:
> OK, here's the WIP patch for the unified core/ecpg grammar,
> with opt_from_in. But I am still getting the 2 shift/reduce
> conflicts exactly for the FORWARD and BACKWARD rules
> that I was getting originally. Can you look at this patch and
> p
Boszormenyi Zoltan írta:
> Tom Lane írta:
>
>> Boszormenyi Zoltan writes:
>>
>>
>>> Tom Lane írta:
>>>
>>>
>>>> I'd look at requiring from_in as being the least-bad alternative.
>>>>
>
Michael Meskes írta:
> On Sat, Aug 08, 2009 at 04:57:57PM -0400, Tom Lane wrote:
>
>> The fundamental reason that there's a problem here is that ecpg has
>> decided to accept a syntax that the backend doesn't (ie, FETCH with a
>> fetch direction but no FROM/IN). I think that that's basically a
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Tom Lane írta:
>>
>>> I'd look at requiring from_in as being the least-bad alternative.
>>>
>
>
>> Hm. "FETCH FORWARD variable" can only be a rowcount var
>> onl
Boszormenyi Zoltan írta:
> Tom Lane írta:
>
>> I wrote:
>>
>>
>>> The fundamental reason that there's a problem here is that ecpg has
>>> decided to accept a syntax that the backend doesn't (ie, FETCH with a
>>> fetch di
Tom Lane írta:
> I wrote:
>
>> The fundamental reason that there's a problem here is that ecpg has
>> decided to accept a syntax that the backend doesn't (ie, FETCH with a
>> fetch direction but no FROM/IN). I think that that's basically a bad
>> idea: it's not helpful to users to be inconsiste
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Tom Lane írta:
>>
>>> I'd look at requiring from_in as being the least-bad alternative.
>>>
>
>
>> Hm. "FETCH FORWARD variable" can only be a rowcount var
>> onl
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Michael Meskes Ărta:
>>
>>> The problem is that SignedIconst might be a char variable,
>>> too. So how shall the parser know whether str in "FETCH BACKWARD :str"
>>> carries
>>
Michael Meskes írta:
> On Sat, Aug 08, 2009 at 07:21:59PM +0200, Boszormenyi Zoltan wrote:
>
>>> A possible solution
>>> would be to force a numeric variable for numeric data.
>>>
>> By which you would remove a feature.
>> With the proposed
Michael Meskes írta:
> On Sat, Aug 08, 2009 at 05:48:57PM +0200, Boszormenyi Zoltan wrote:
>
>> ...
>> "/usr/bin/perl" ./parse.pl . < ../../../../src/backend/parser/gram.y >
>> preproc.y
>> /usr/bin/bison -d -o preproc.c preproc.y
>> preproc
Tom Lane írta:
> Michael Meskes writes:
>
>> Tom, AFAICT we only need one core grammar change, moving the cursor name to
>> it's own rule that only resolves back to name. This rule should be eliminated
>> by bison during the build process anyway, so I see no problem adding it. It
>> does make t
Michael Meskes írta:
> On Mon, Aug 03, 2009 at 06:59:30PM +0200, Boszormenyi Zoltan wrote:
>
>>> Why is this messing with the core grammar?
>>>
>> ...
>>
>
> Zoltan, could you please explain why you unrolled FORWARD and BACKWARD? I
> tri
Michael Meskes írta:
> On Fri, Aug 07, 2009 at 12:08:00PM -0400, Alvaro Herrera wrote:
>
>> I think we're normally OK with mentioning the authors, i.e. "Author:
>>
>
> Yes, it's OK, but I think we normally only acknowledge the author in our
> commit
> messages, don't we?
>
>
>> such and
Michael Meskes írta:
> On Fri, Aug 07, 2009 at 11:48:33AM +0200, Boszormenyi Zoltan wrote:
>
>> Which isn't exactly a good programming habit.
>>
>
> I couldn't agree more.
>
:-)
>> In the above code local, in-scope variables are also r
Michael Meskes írta:
> On Fri, Aug 07, 2009 at 01:05:33PM +0200, Boszormenyi Zoltan wrote:
>
>> Hey, thanks. Did you only commit this, or all of
>> those in the patchset? Exluding the nonfix for
>> the struct problem of course.
>>
>
> So far only this
Michael Meskes írta:
> On Mon, Aug 03, 2009 at 06:12:43PM +0200, Boszormenyi Zoltan wrote:
>
>> - string support: I am doing much less now unconditionally,
>> most of the parser changes (e.g. introducing STRING_P)
>> were unnecessary to make it working.
>>
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 04:22:53PM +0200, Boszormenyi Zoltan wrote:
>
>> If you meant like this below, then ECPG segfaults on this too:
>>
>
> Right, because arrays as as well unimplemented as are structs. I meant
> something like thi
Tom Lane írta:
> At the moment it looks to me like pg_migrator has crashed and burned
> for 8.4, at least for general-purpose usage.
It means that you don't have the restraint that
you thought you have. So you can change the
RedHat/Fedora PostgreSQL 8.4 packages to use
the upstream default for int
Boszormenyi Zoltan írta:
> Michael Meskes írta:
>
>> On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
>>
>>
>>> I have looked at it. The code seems to be invalid.
>>>
>>>
>> Yes, it is, I was t
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 03:04:00PM +0200, Boszormenyi Zoltan wrote:
>
>> My question is: why not unroll the struct in the preprocessor?
>>
>
> The problem is not that the struct is unrolled in the preprocessor. I just
> don't like the
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
>
>> I have looked at it. The code seems to be invalid.
>>
>
> Yes, it is, I was too lazy to make it valid. If you just allocate the memory
> for the variable in get_var()
Michael Meskes írta:
>> I confess I haven't been following the ECPG threads real closely, but
>> I'm confused as to the status of the following two patches. Have you
>> reviewed these? If so, what was the outcome? If not, do you plan to?
>>
>
> I did a first review and then left for my vaca
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 11:52:57AM +0200, Boszormenyi Zoltan wrote:
>
>> This means that what I did in my first patch for this
>> problem in "add_struct_to_head()" (unrolling members
>> of the struct) has to be done in adjust_informix
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
>
>> I have looked at it. The code seems to be invalid.
>>
>
> Yes, it is, I was too lazy to make it valid. If you just allocate the memory
> for the variable in
Michael Meskes írta:
> On Fri, Jul 31, 2009 at 11:42:33AM +0200, Boszormenyi Zoltan wrote:
>
>> made me look around more. Find the attached patch I came up with.
>> Now my previous test code works and produces similar C code
>> as without "-C INF
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> new versions attached, updated to apply to the current CVS cleanly.
>>
>
> Why is this messing with the core grammar?
>
> regards, tom lane
>
It was explained in earlier mails,
Michael Meskes írta:
> On Fri, Jul 17, 2009 at 03:58:21PM +0200, Boszormenyi Zoltan wrote:
>
>> Attached is the short example I can reproduce with.
>> The version I used was final PostgreSQL 8.4.0, without our
>> extensions posted already. I added an indication to ec
Alvaro Herrera írta:
> Boszormenyi Zoltan wrote:
>
>
>> The vague consensus for syntax options was that the GUC
>> 'lock_timeout' and WAIT [N] extension (wherever NOWAIT
>> is allowed) both should be implemented.
>>
>> Behaviour would be that N s
Alvaro Herrera írta:
> Boszormenyi Zoltan wrote:
>
>> Alvaro Herrera írta:
>>
>>> Boszormenyi Zoltan wrote:
>>>
>>>
>>>> The vague consensus for syntax options was that the GUC
>>>> 'lock_timeout' and
Alvaro Herrera írta:
> Boszormenyi Zoltan wrote:
>
>
>> The vague consensus for syntax options was that the GUC
>> 'lock_timeout' and WAIT [N] extension (wherever NOWAIT
>> is allowed) both should be implemented.
>>
>> Behaviour would be that N s
Bruce Momjian írta:
> Hans-Juergen Schoenig wrote:
>
>> hello everybody,
>>
>> from my side the goal of this discussion is to extract a consensus so
>> that we can go ahead and implement this issue for 8.5.
>> our customer here needs a solution to this problem and we have to come
>> up with so
Michael Meskes írta:
> On Wed, Jul 15, 2009 at 07:17:17PM +0200, Böszörményi Zoltán wrote:
>
>> as asked by Michael Meskes, I have split up our ECPG patchset:
>>
>
> Just a couple quick comments.
>
> It appears to me (without much testing) that the patches still partly rely on
> each other.
Michael Meskes írta:
> On Fri, Jul 17, 2009 at 12:27:49PM +0200, Boszormenyi Zoltan wrote:
>
>> one of our clients wants to port their application suite
>> from Informix to PostgreSQL, they use constructs like
>>
>> SELECT * INTO :tablerec FROM table ...
>>
&
Hi,
one of our clients wants to port their application suite
from Informix to PostgreSQL, they use constructs like
SELECT * INTO :tablerec FROM table ...
where "tablerec" mirrors the table fields in a C struct.
Currently ECPG dumps core on this, more exactly aborts on it
in ecpg_type_name().
P
Michael Meskes írta:
> On Sat, Jul 04, 2009 at 05:09:04PM +0200, Boszormenyi Zoltan wrote:
>
>> OK, let me retry. This version treats "string" as a non-reserved word,
>> and also discovers whether the PGC contains this construct below,
>> as in ecpg/tests/pre
Michael Meskes írta:
> On Sat, Jul 04, 2009 at 03:39:14PM +0200, Boszormenyi Zoltan wrote:
>
>> The attached patch is built upon our previous patch supporting
>> dynamic cursor and SQLDA.
>>
>
> Please don't do this unless the new patch relies on s
Hi,
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> in a continued effort for better Informix ESQL/C compatibility,
>> we added the "string" pseudo-type handling to ECPG.
>> ...
>> - "string" has become a type name, reserved word in ECPG.
Hi,
in a continued effort for better Informix ESQL/C compatibility,
we added the "string" pseudo-type handling to ECPG.
This type in ESQL/C is documented as:
--
The string Data Type
The string data type is an ESQL/C data type that holds character d
Josh Berkus írta:
>
>> But more generally, what you are proposing seems largely duplicative
>> with statement_timeout. The only reason I can see for a
>> lock-wait-specific timeout is that you have a need to control the
>> length of a specific wait and *not* the overall time spent. Hans
>> alread
Greg Stark írta:
> 2009/5/11 Boszormenyi Zoltan :
>
>> Does statement_timeout counts against subtransactions as well? No.
>> If a statement finishes before statement_timeout, does it also decrease
>> the possible runtime for the next statement? No. I was talking about
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Tom Lane írta:
>>
>>> I think the way you're describing would be both harder to implement
>>> and full of its own strange traps.
>>>
>
>
>> Why?
>>
>
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Would the "lock_timeout" work for all to be acquired locks individually,
>> or all of them combined for the statement? The individual application
>> of the timeout for every locks individually wouldn't b
Hi,
Tom Lane írta:
> Hans-Juergen Schoenig writes:
>
>> i would like to propose an extension to our SELECT FOR UPDATE mechanism.
>> especially in web applications it can be extremely useful to have the
>> chance to terminate a lock after a given timeframe.
>>
>
> I guess my immediate rea
Hi,
we have come across a theoretical problem with a GIS database,
which I think worth discussing.
The database table is partitioned, it's already larger than 30TB.
The table is partitioned over the PostGIS && (overlaps) operator.
However, when SELECTing from that table, it goes through all
parti
Bruce Momjian írta:
> I have written a presentation about the major 8.4 features known so far:
>
> http://momjian.us/main/writings/pgsql/features.pdf
>
> Comments? Suggestions? Please email me offlist and I will update the
> PDF.
>
>
The title "Save termination of individual sessions" s
401 - 480 of 480 matches
Mail list logo
