>
> My vote is "tough, time to fix your SQL code".
>
Sounds good to me, but please document it in the "migration" notes. No need
for a surprise.
Regards,
Jeff
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unre
On Thu, Sep 12, 2002 at 03:18:13PM -0400, Tom Lane wrote:
> Sure --- and that is exactly *not* what the backend facility does. In
> the backend PREPARE you supply the statement to be prepared directly in
> the same SQL command, not as the value of some variable.
The variable will be replaced by
> Hmm, looks like all the conversion_procs files have
>
> Assert(len > 0);
>
> Surely that should be Assert(len >= 0)?
>
> I also notice that I neglected to change PG_RETURN_INT32(0) to
> PG_RETURN_VOID() in these files. That's only cosmetic, but
> probably it should be done.
Fixed.
--
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> escribió:
>> Actually, there might not be a problem. c1.name can't be deleted until
>> both p1.name and p2.name go away, and at that point we want both c1.name
>> and gc1.name to go away. So as long as we don't *recursivel
Hi everyone,
An interesting development.
Afilias and LibertyRMS, the people who've been happily running the .info
namespace on PostgreSQL servers, are the technical backend of the ISOC
application for management of the .org
namespace. However, ICANN is asking for more detail about the backend
d
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What I want to know is how different from B+-trees are PostgreSQL
> B-trees;
PG's "btrees" are in fact B+-trees according to the more formal
academic notation. IIRC the + just indicates allowing any number
of keys/downlinks in an internal tree node.
En Fri, 13 Sep 2002 00:46:00 -0400
Tom Lane <[EMAIL PROTECTED]> escribió:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> > Sure it is. The float=>int casts need to be made implicit, or we'll have
> > tons of problems like this.
>
> Well, yeah. That did not seem to bother anyone last sprin
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Bruce Momjian writes:
> >> I would love to say that this is related to change in casts, but that
> >> isn't the case.
>
> > Sure it is. The float=>int casts need to be made implicit, or
> we'll have
> > tons of problems like this.
>
> Well, ye
En Thu, 12 Sep 2002 23:40:21 -0400
Tom Lane <[EMAIL PROTECTED]> escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > If this is not clear, imagine the following situation:
>
> > create table p1(id int, name text);
> > create table p2(id2 int, name text);
> > create table c1(age int) inheri
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> I would love to say that this is related to change in casts, but that
>> isn't the case.
> Sure it is. The float=>int casts need to be made implicit, or we'll have
> tons of problems like this.
Well, yeah. That did not see
Hello!
I recommend two good sources of information in English:
http://www.nist.gov/dads/ further look for balanced trees and kins
(BTW, there is some other interesting algorithms alike patricia).
and well-known Donald Knuth's monography, namely, volume 3. (I mean
"The Art of Computer Programmi
Philip Warner <[EMAIL PROTECTED]> writes:
> ISTM that this problem comes about because we allow an external function to
> be defined incorrectly (ie. the db says it returns type A, the function
> really returns type B) - and we should be addressing that problem.
Well, yeah. 7.3 is trying to ti
Philip Warner <[EMAIL PROTECTED]> writes:
> At 11:27 PM 12/09/2002 -0400, Tom Lane wrote:
>> You mean hardwire the names "plpgsql_language_handler", etc, as being
>> ones that should return such-and-such instead of OPAQUE?
> No; I actually mean modifying the function definition macros
> (PG_FUNC
At 01:42 PM 13/09/2002 +1000, Philip Warner wrote:
>Not all functions would need to use these, but when a user defines a
>function they could be checked. And in the case of the plpgsql handlers,
>they would of course be defined.
ISTM that this problem comes about because we allow an external f
Hackers,
I'm starting to read the existing algorithms for btree index shrinking.
Right now I'm at 1996 SIGMOD proceedings, Zou and Salzberg "On-line
Reorganization of Sparsely-populated B+-trees".
What I want to know is how different from B+-trees are PostgreSQL
B-trees; I've read the README in
At 11:27 PM 12/09/2002 -0400, Tom Lane wrote:
>You mean hardwire the names "plpgsql_language_handler", etc, as being
>ones that should return such-and-such instead of OPAQUE?
No; I actually mean modifying the function definition macros
(PG_FUNCTION_INFO etc) to allow function definitions to (opt
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> If this is not clear, imagine the following situation:
> create table p1(id int, name text);
> create table p2(id2 int, name text);
> create table c1(age int) inherits(p1,p2);
> create table gc1() inherits (c1);
> p1 and p2 have name->attisinherited=0
Philip Warner <[EMAIL PROTECTED]> writes:
> At 01:37 PM 12/09/2002 -0400, Tom Lane wrote:
>> Er ... what has that got to do with this?
> When a user issues a 'CREATE FUNCTION' call, the fmgr can check the return
> type, and create it with the correct return type (with warning). We just
> need t
En 12 Sep 2002 17:23:41 +0200
Hannu Krosing <[EMAIL PROTECTED]> escribió:
> The other sad thing about the current behaviour is that in addition to
> being wrong it also breaks dump/reload - after dump/reload the initially
> dropped column is back in c1.
I hadn't read this paragraph before. But
Tom Lane dijo:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>
> > The count approach seems definitely the right way, but a check (possibly
> > a slow one) can be probably done without initdb.
>
> Slow, complicated to code, and deadlock-prone (since you'd have to
> acquire locks on the other par
> Setting locales (LC_ALL) is now best done as an option to initdb. Be sure
> to update pkg-message to that effect. Also, the encoding should be
> specified to initdb (rather than configure --enable-multibyte=ENCODING).
I guess --enable-multibyte=ENCODING does nothing with 7.3
--
Tatsuo Ishii
At 01:37 PM 12/09/2002 -0400, Tom Lane wrote:
> > What about extending the function manager macros to know about return
> types
> > (at least for builtin types)?
>
>Er ... what has that got to do with this?
When a user issues a 'CREATE FUNCTION' call, the fmgr can check the return
type, and cre
On Fri, 13 Sep 2002, Peter Eisentraut wrote:
> Alvaro Herrera writes:
>
> > Is there some documentation on TOAST?
>
> No. Why do you need any?
I think I saw some docs in the
/usr/local/src/postgresql-7.2.1/src/backend/access/heap/tuptoaster.c
file on my box. :-)
Actually it is pretty wel
Sean Chittenden writes:
> I've put together some packages for the 7.3beta1 release. The can be
> found here along with a tenative FreeBSD port:
>
>http://66.250.180.19/postgresql-7.3beta1/
I checked out this port and made some notes that you might find useful.
[Makefile]
You can remove -
Alvaro Herrera writes:
> Is there some documentation on TOAST?
No. Why do you need any?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Bruce Momjian writes:
> Wow. That is clear. Why are we returning "year" as a double?
Because we've been doing that for many years.
> I would love to say that this is related to change in casts, but that
> isn't the case.
Sure it is. The float=>int casts need to be made implicit, or we'll ha
Giles Lean <[EMAIL PROTECTED]> writes:
>> Rod Taylor <[EMAIL PROTECTED]> writes:
>>> ALTER TABLE FKTABLE ADD FOREIGN KEY(ftest1) references
>>> pktable(ptest1);
>>> NOTICE: ALTER TABLE will create implicit trigger(s) for FOREIGN KEY
>>> check(s)
>>> + ERROR: Relation "pg_temp_5"."" does not exis
Barry Lind <[EMAIL PROTECTED]> writes:
> ... I don't understand
> why the timings for prepared statements would be less than for a regular
> statement, and especially why using bind variables would be better than
> without. I am concerned that prepared statements may be choosing a
> different exe
Hi everyone,
We're looking to get an initial "PostgreSQL Advocacy and Marketing" site
up an running in the next day or so.
Whilst we know of a reasonable number of large places running PostgreSQL
(as shown on the
http://techdocs.postgresql.org/techdocs/supportcontracts.php page),
we're still loo
Karel Zak <[EMAIL PROTECTED]> writes:
> In the server log file is:
> TRAP: FailedAssertion("!(len > 0)", File: "utf8_and_iso8859_1.c", Line: 45)
Hmm, looks like all the conversion_procs files have
Assert(len > 0);
Surely that should be Assert(len >= 0)?
I also notice that I neglected
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Thu, Sep 12, 2002 at 09:07:20AM -0400, Tom Lane wrote:
>> But you must implement your own PREPARE/EXECUTE anyway, using ecpg
>> variables, no?
> In ecpg you can use a string variable or constant holding the statement
> to prepare that statement as i
Curt Sampson <[EMAIL PROTECTED]> writes:
> On Thu, 12 Sep 2002, Justin Clift wrote:
>> Am just wondering if we've ever considered adding a PGXLOG environment
>> variable that would point to the pg_xlog directory?
> IMHO, a much better way to support this is to put this information into
> the conf
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I would love to say that this is related to change in casts, but that
> isn't the case. It is the new double-precision handling of dates;
You've got that exactly backwards: date_part has always returned double.
regards, tom lan
Hi,
Does anyone know any implementation of a fixpoint operator (recursive
queries) for postgreSQL?
Thanks,
Luciano.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Thu, 2002-09-12 at 15:54, Tom Lane wrote:
>> Only if people dump their old databases with 7.3 pg_dump; which is an
>> assumption I'd rather not make if we can avoid it.
> I don't understand.
> The only pg_dump we can fix is 7.3.
Certainly. But if
Philip Warner <[EMAIL PROTECTED]> writes:
> At 10:31 AM 12/09/2002 -0400, Tom Lane wrote:
>> Does anyone see a cleaner answer than re-allowing OPAQUE for PL
>> handlers?
> What about extending the function manager macros to know about return types
> (at least for builtin types)?
Er ... what has
I wrote:
> scott.marlowe wrote:
>>
>> I wouldn't assume that. It's been years since I tested it, but back
>> then, the command line and all program I used could see the link
>> created by ln that came with the resource kit. They were distinctly
>> different from the shortcut type of links, i
Oliver Elphick wrote:
On Thu, 2002-09-12 at 15:54, Tom Lane wrote:
Oliver Elphick <[EMAIL PROTECTED]> writes:
On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
Does anyone see a cleaner answer than re-allowing OPAQUE for PL
handlers?
On Thu, 12 Sep 2002, scott.marlowe wrote:
> Agreed.
>
> Actually, an argument could likely be made that changes that require
> initdb should be done as early as possible since the later the change the
> more people there will be to test the change, and there will be fewer
> people who actuall
On Thu, 2002-09-12 at 15:54, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
> >> Does anyone see a cleaner answer than re-allowing OPAQUE for PL
> >> handlers?
>
> > Can't you just special case the language handlers when dumping <7.3
scott.marlowe wrote:
> On Fri, 13 Sep 2002, Justin Clift wrote:
>
>>Would it be correct to say that the 'ln' command in the MS Resource Kit
>>creates this kind of shortcut too, as the Reparse Points feature doesn't
>>seem to be possible under NT4?
>
>
> I wouldn't assume that. It's been years
On Thu, 12 Sep 2002, Matthew T. OConnor wrote:
> > > The count approach seems definitely the right way, but a check (possibly
> > > a slow one) can be probably done without initdb.
> >
> > We can certainly do the proper fix in 7.4; do we consider this bug
> > important enough to do an initdb for
On Thu, 12 Sep 2002, Justin Clift wrote:
> Am just wondering if we've ever considered adding a PGXLOG environment
> variable that would point to the pg_xlog directory?
IMHO, a much better way to support this is to put this information into
the config file. That way it can't easily change when yo
Dave Page wrote:
> Oliver reported:
>
> 2. The dump produced:
> CREATE TABLE cust_alloc_history (
> ...
> "year" integer DEFAULT date_part('year'::text,
> ('now'::text)::timestamp(6) with time zone) NOT NULL,
> ...
> ERROR: Column "year" is of
> > The count approach seems definitely the right way, but a check (possibly
> > a slow one) can be probably done without initdb.
>
> We can certainly do the proper fix in 7.4; do we consider this bug
> important enough to do an initdb for 7.3beta2? I don't have a strong
> feeling either way abou
On Fri, 13 Sep 2002, Justin Clift wrote:
> "scott.marlowe" wrote:
>
> > > Seems like the NT4 users are left out in the cold though until we add
> > > some kind of ability for PostgreSQL to not look at the filesystem for
> > > info about where to put the xlog files.
> >
> > This isn't true. Wit
scott.marlowe wrote:
> > Seems like the NT4 users are left out in the cold though until we add
> > some kind of ability for PostgreSQL to not look at the filesystem for
> > info about where to put the xlog files.
>
> This isn't true. With the resource kit, you get the gnu utils, and ln
> works
"scott.marlowe" wrote:
> > Seems like the NT4 users are left out in the cold though until we add
> > some kind of ability for PostgreSQL to not look at the filesystem for
> > info about where to put the xlog files.
>
> This isn't true. With the resource kit, you get the gnu utils, and ln
> work
Hi,
I have file with this code:
--
\l
SHOW SERVER_ENCODING;
SHOW CLIENT_ENCODING;
--- Languages table
---
CREATE TABLE lang
(
--- 'id' is here lang abbreviation
---
id varchar(3) PRIMARY KEY,
namevarchar(16) NOT NULL--- lan
Does anyone know if such effort is also required to pl/python to become
"schema aware"?
Regards,
Greg Copeland
On Wed, 2002-09-11 at 19:24, Bruce Momjian wrote:
>
> Patch applied. Thanks.
>
> ---
>
>
> Joe Con
On Thu, 12 Sep 2002, Justin Clift wrote:
> Mike Mascari wrote:
>
> > In Windows 2000 and Windows XP with an NTFS filesystem,
> > Microsoft has added Reparse Points, which allow for the
> > implementation of symbolic links for directories. Microsoft
> > calls them "Junctions". I *believe* the fun
At 10:31 AM 12/09/2002 -0400, Tom Lane wrote:
>Does anyone see a cleaner answer than re-allowing OPAQUE for PL
>handlers?
What about extending the function manager macros to know about return types
(at least for builtin types)?
P
On Thu, Sep 12, 2002 at 09:07:20AM -0400, Tom Lane wrote:
> Michael Meskes <[EMAIL PROTECTED]> writes:
> > I'm awfully sorry that I missed this thread. But I do not really
> > understand the problem. If we cannot be exactly as specified why aren't
> > we coming close? As it stands now I have to im
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
>> Does anyone see a cleaner answer than re-allowing OPAQUE for PL
>> handlers?
> Can't you just special case the language handlers when dumping <7.3 and
> change 'RETURNS opaque' to 'RETURNS language_handle
On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
> Does anyone see a cleaner answer than re-allowing OPAQUE for PL
> handlers?
Can't you just special case the language handlers when dumping <7.3 and
change 'RETURNS opaque' to 'RETURNS language_handler'? That's all that
is needed to let them be resto
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> Hm. Seems like attisinherited should have been a count, not a boolean.
>> Is anyone sufficiently excited about this issue to force an initdb to
>> fix it?
> The count approach seems definitely the right way, but a check (possibly
> a slow one) can be
Tom Lane dijo:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > I've come upon a misbehaviour of drop column, where drop column
> > unconditionally drops inherited column from child tables.
> > What it should do is to check if the same column is not inherited from
> > other parents and drop it on
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, our whole goal was to get rid of the opaque thing entirely so I am
> not sure if we want to keep that going. In fact, I am not sure it is
> even possible to remap opaque because it now is represented by so many
> other values.
We do still allow O
On Thu, 2002-09-12 at 16:14, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > I've come upon a misbehaviour of drop column, where drop column
> > unconditionally drops inherited column from child tables.
> > What it should do is to check if the same column is not inherited from
> >
Hannu Krosing <[EMAIL PROTECTED]> writes:
> I've come upon a misbehaviour of drop column, where drop column
> unconditionally drops inherited column from child tables.
> What it should do is to check if the same column is not inherited from
> other parents and drop it only when it is not
Hm. See
Michael Meskes <[EMAIL PROTECTED]> writes:
> I'm awfully sorry that I missed this thread. But I do not really
> understand the problem. If we cannot be exactly as specified why aren't
> we coming close? As it stands now I have to implement my own
> PREPARE/EXECUTE in ecpg and the syntax does clash
Mike Mascari wrote:
> In Windows 2000 and Windows XP with an NTFS filesystem,
> Microsoft has added Reparse Points, which allow for the
> implementation of symbolic links for directories. Microsoft
> calls them "Junctions". I *believe* the function used for
> creating reparse points is DeviceIoCo
On Thu, 2002-09-12 at 00:52, Philip Warner wrote:
> At 12:31 PM 9/09/2002 +0100, Oliver Elphick wrote:
> >3. A view is being created before one of the tables it refers to.
> >Should not views be created only at the very end?
>
> This would be trivial (and we already put several items at the end),
Dave Page wrote:
>
>>-Original Message-
>>From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
>>
>>Also, I have heard symlinks are available in native Windows
>>but the interface to them isn't clearly visible. Can someone
>>clarify that?
>
>
> Well there are 'shortcuts' but I wouldn't wa
On Wed, Sep 11, 2002 at 04:36:31PM -0400, Tom Lane wrote:
> IIRC, the conclusion of our earlier debate about backend PREPARE/EXECUTE
> syntax was that since it was not implementing exactly the behavior
> specified for embedded SQL (and couldn't, not being an embedded
> operation) it would be bette
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 12 September 2002 06:27
> To: Justin Clift
> Cc: PostgreSQL Hackers Mailing List
> Subject: Re: [HACKERS] PGXLOG variable worthwhile?
>
> Also, I have heard symlinks are available in native Windows
> but the
66 matches
Mail list logo
