Tom Lane wrote:
> Josh Berkus writes:
>
>>>True, but there were clear benefits from doing so. Disallowing "="
>>>assignment in plpgsql wouldn't buy anything, just break programs.
>
>
>>But it's already disallowed in most places.
>
>
> No it isn't. The plpgsql scanner treats := and = as *the
The function
static int32 text_position(text *t1, text *t2, int matchnum)
defined in src/backend/utils/adt/varlena.c uses repeated calls to strncmp (or
pg_wchar_strncmp) to find the location of the pattern in the text. The worst
case runtime for such an approach is O(n*m) where n and m are the
Stephan Szabo wrote:
> On Wed, 17 May 2006, Tom Lane wrote:
>
>
>>Stephan Szabo <[EMAIL PROTECTED]> writes:
>>
>>>Per the report from Clark C Evans a while back and associated discussion,
>>>it seems like recent versions of the SQL spec changed the rules for
>>>foreign key column references such
David Wheeler wrote:
> On May 16, 2006, at 16:53, Mark Dilger wrote:
>
>> Sorry, I meant to say that it should only be a no-op according to the
>> language
>> specification, as I understand it. The fact that it works suggests
>> to me that
>> the implemen
Mark Dilger wrote:
> David Wheeler wrote:
>
>>Hellow PostgreSQL hackers,
>>
>>Quick question. Why does the 'i = i + 1' syntax work in this PL/pgSQL
>>function?
>>
>>try=# CREATE OR REPLACE FUNCTION inc_by_two(
>>try(#upfrom int,
>
David Wheeler wrote:
> Hellow PostgreSQL hackers,
>
> Quick question. Why does the 'i = i + 1' syntax work in this PL/pgSQL
> function?
>
> try=# CREATE OR REPLACE FUNCTION inc_by_two(
> try(#upfrom int,
> try(#upto int
> try(# ) RETURNS SETOF INT AS $$
> try$# BEGIN
> try$# FOR i
Joshua D. Drake wrote:
> Hello,
>
> I was dinking around wand came across something that may (or may not be
> useful).
>
> What if single line statements that were seperated by ; within psql were
> implicitly within a transaction?
>
> E.g;
>
> postgres=# select * from foo; update foo set bar =
Martijn van Oosterhout wrote:
> On Wed, May 10, 2006 at 09:41:46AM +0200, Mario Weilguni wrote:
>
Could we make BEGIN fail when we already are in a transaction?
>>>
>>>We could, but it'd probably break about as many apps as it fixed.
>>>I wonder whether php shouldn't be complaining about this,
[EMAIL PROTECTED] wrote:
> On Sun, Apr 30, 2006 at 09:14:53AM -0700, Mark Dilger wrote:
>
>>Tom Lane wrote:
>>
>>>1. A serial column is a "black box" that you're not supposed to muck with
>>>the innards of. This philosophy leads to the propos
Tom Lane wrote:
> 1. A serial column is a "black box" that you're not supposed to muck with
> the innards of. This philosophy leads to the proposal that we disallow
> modifying the column default expression of a serial column, and will
> ultimately lead to thoughts like trying to hide the associat
Should we make the whole postgres logging system configurable, similar to log4j
(or log4perl) rather than special-casing the autovacuum logs? Do we want to see
options added piecemeal to the conf file such as "autovacuum_messages=silent"?
mark
---(end of broadcast)---
Tom Lane wrote:
> I would really prefer to see CREATE AGGREGATE normalized to have a
> syntax comparable to CREATE FUNCTION (or DROP AGGREGATE for that
> matter):
> CREATE AGGREGATE aggname (typname [, ... ]) ...definition...
> but it's not clear how to get there without breaking backwards
>
Jonah H. Harris wrote:
> As long as it's optional, I guess it's OK to let the administrator
> deal with recovery. Of course, in addition to no-fsync, we'll have
> another *possibly* dangerous option. BTW, I've seen no-fsync used far
> too many times because people think they're hardware is invin
Thomas Hallgren wrote:
> Martijn,
>
> I tried a Socket approach. Using the new IO stuff that arrived with Java
> 1.4 (SocketChannel etc.), the performance is really good. Especially on
> Linux where an SMP machine show a 1 to 1.5 ratio between one process
> doing ping-pong between two threads and
Peter Eisentraut wrote:
Mark Dilger wrote:
Looking through the postgresql source code, I notice that there are
many places were palloc is used but the return value is not checked
to see if it is null.
palloc will throw an exception if it cannot fulfill the request. Code
that checks the
Looking through the postgresql source code, I notice that there are many places
were palloc is used but the return value is not checked to see if it is null.
There are a few places such as:
if (!PointerIsValid(result = palloc(CASH_BUFSZ + 2 - count +
strlen(nsymbol
Attached is the new patch. To summarize:
- new function justify_interval(interval)
- modified function justify_hours(interval)
- modified function justify_days(interval)
These functions are defined to meet the requirements as discussed in this
thread. Specifically:
- justify_hours m
Tom Lane wrote:
My concern about how nicely libstdc++ will play in the backend
environment still stands though.
I have had the same concern, though never any hard evidence of a problem. If
the C++ functions are wrapped with "extern C", and all exceptions caught
(perhaps converted into error
I've written the interval_justify() function but the parser does not know about
it yet. I changed these files:
backend/utils/adt/timestamp.c
include/catalog/pg_proc.h
include/utils/timestamp.h
I used grep -R to find all locations where interval_justify_time is mentioned,
and for each on
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
If so, one function or the other is cheating.
That depends what you mean by cheating. The justify_hours function
looks to see what answer justify_days would give, but does not
actually change the data. I des
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
justify_days(justify_hours(...)) fixes *everything* in the most recently
submitted patch, regardless of the convoluted case you invent. There is no data
for which it won't work.
If so, one function or the other is che
Bruce Momjian wrote:
Even if we had people do:
justify_hours(justify_days(justify_hours()))
I don't think that would do what we want in all cases. Consider '1 mon
-1 hour'. That should be '29 days 23 hours' but neither existing
function, even if modified, will allow us to return that.
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
This overall design seems more flexible than Tom's recent post in which he
stated that justify_days should call justify_hours internally.
AFAIR I said the exact opposite.
regards, tom lane
Tom Lane
Tom Lane wrote:
Well, the question is whether justify_days has a sane definition that is
different from this. Based on your example, I'm not seeing one.
Backwards compatibility is probably more important than sanity. Let's just
deprecate the existing functions and recommend that people use
Bruce Momjian wrote:
If we do that, we should just call it justify_interval(). I am thinking
this is the direction to go, and for people who want more control they
use the justify_hours and justify_days, and those are left unchanged.
I agree. Let's leave the existing functions alone. I can r
Tom Lane wrote:
> Mark Dilger <[EMAIL PROTECTED]> writes:
>
>>Am I correct that the second case should still have negative hours?
>
>
> Yes...
>
>
>>If so, then justify_hours(...) needs to examine the sign of the days
>>and months portion of the int
A new patch is attached. Please note the regression differences.
mark
Index: src/backend/utils/adt/timestamp.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v
retrieving revision 1.160
diff --context=5 -
Bruce Momjian wrote:
Mark Dilger wrote:
Your proposal is that justify_hours borrows 24 hours from the days column in
order to bring the -12 hours up to a positive 12 hours. Should it only do that
if the days column is a positive number? What if it is negative?
I think we all agree on the
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
The current code (without the patch) behaves as follows:
select justify_days(justify_hours('1 month 95 days -36:00:00'::interval));
justify_days
-
4 mons 4 days -12:00:00
So?
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I guess I would expect a good result to satisfy one of these three
cases:
* month > 0 and 0 <= day < 30
* month < 0 and -30 < day <= 0
* month = 0 and -30 < day <
Hannu Krosing wrote:
But unfortunately '2 mons -1 days' <> '1 mons 29 days'
If I want something to happen 1 day less than two months from dome date,
then the only way to say that consistently *is* '2 mons -1 days'.
Correct me if I am wrong, but I thought that justify_days would only be called
Tom Lane wrote:
Bruce Momjian writes:
I don't think we can accept a change that takes a negative and turns it
into a positive and negative.
Yeah, I find the patch's changes to the regression results pretty
disturbing.
Perhaps the correct definition ought to be like "if month part >= 0
then
Mark Dilger wrote:
Tom Lane wrote:
"Milen A. Radev" <[EMAIL PROTECTED]> writes:
Milorad Poluga напи�а:
SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15
days'::interval
?column?--- 3 mons -14 days
Why not '
Tom Lane wrote:
"Milen A. Radev" <[EMAIL PROTECTED]> writes:
Milorad Poluga напи�а:
SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15 days'::interval
?column?
---
3 mons -14 days
Why not '2 mons 16 days' ?
Please read the last paragraph in sect
byteaoctetlen/textoctetlen
calls toast_raw_datum_size.
On Sat, 11 Feb 2006, Bruce Momjian wrote:
Have you looked at the 8.1.X buildin function pg_column_size()?
---
Mark Dilger wrote:
Hello, could anyone tell me, for
Bruce Momjian wrote:
Have you looked at the 8.1.X buildin function pg_column_size()?
Thanks Bruce for the lead. I didn't know what to grep for; this helps.
The header comment for that function says
"Return the size of a datum, possibly compressed"
I take it the uncompressed length i
Hello, could anyone tell me, for a user contributed variable length data type,
how can you access the length of the data without pulling the entire thing from
disk? Is there a function or macro for this?
As a first cut, I tried using the PG_DETOAST_DATUM_SLICE macro, but to no avail.
grep'in
Mark Dilger wrote:
I've been thinking about this more, and now I don't see why this is an
issue. When the planner estimates how many rows will be returned from a
subquery that is being used within a join, it can't know which
"parameters" to use either. (Parameters bein
Josh Berkus wrote:
Tom,
What I'd like to do is implement the constant method for 8.2, and work
on doing the S() method later on. Does that make sense?
I'm not thrilled with putting in a stopgap that we will have to support
forever. The constant method is *clearly* inadequate for many (prob
Josh Berkus wrote:
Mark,
This would only seem to work for trivial functions. Most functions that
I write are themselves dependent on underlying tables, and without any
idea how many rows are in the tables, and without any idea of the
statistical distribution of those rows, I can't really say
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
If we are talking about inserting the function definition into the
query as a subquery and then letting the parser treat it as a
subquery, then I see no reason to use either the existing function or
view subsystems. It sounds mor
Josh Berkus wrote:
Tom,
As for the dependency issue, one man's bug is another man's feature.
I think the fact that we don't track the internal dependencies of
functions is not all bad. We've certainly seen plenty of complaints
about how you can't easily change tables that a view is depending
Tom Lane wrote:
Chris Campbell <[EMAIL PROTECTED]> writes:
True, as long as there's a hook to do the inlining/rewriting before
the query's planned. I guess we can see function calls at the parse
stage, check to see if they're SQL functions or not, grab the prosrc,
do the substitution, then
Daisuke Maki wrote:
> Hi,
>
> First, apologies if my question is a bit off-course. Please feel free to
> direct me to a different mailing list if not appropriate.
>
> I'm currently trying to embed Senna full text search engine
> (http://qwik.jp/senna/) into postgres. I'm trying to achieve this by
Jonah H. Harris wrote:
Mark,
If you don't mind contributing the changes, we'd be glad to take a look
at them. Thanks.
-Jonah
Ok, we will post it back soon. We have tested it on two different 64-bit
architectures (Sparc and AMD) and are now testing on pentium before posting up
to the li
My company has written a 64-bit large object API, extending the postgresql
server to be able to read/write/seek/tell/open/close objects larger than 2GB.
If the hackers community considers this valuable, we will submit the changes
back for the rest of the community to share.
From one of my pro
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
On Tue, Jun 28, 2005 at 07:38:43PM -0700, Mark Dilger wrote:
If, for a given row, the value of c is, say, approximately 2^30 bytes
large, then I would expect it to be divided up into 8K chunks in an
external table, and I sho
bitrarily deep children in a btree type
stored in column "c". It doesn't make sense to have a really wide table to
represent the tree for multiple reasons, mostly involving data duplication in
the leftward columns but also because you can't know ahead of time how wide to
ma
201 - 248 of 248 matches
Mail list logo
