> I have now some time for implement this my suggestion. Or is better
> let down this for 7.2? You are right that it's trivial :-)
I think you should target for 7.2.
> Note: My motivate for this is that I have some multi-language DB
>with Web interface and for current version of PG I m
> Finally, as I've mentioned before I'd like to try out the iconv interface.
> Might become an option in 7.2 even.
I'm curious how do you handle conversion between multibyte strings
and wide characters using iconv. This is necessary to implement
multibyte aware like, regex, char_length etc. funct
I have what may be a half-baked idea for allowing nextval and friends to
work with a true sequence-name parameter, rather than a string
equivalent.
Suppose that we invent a new datatype "regclass", similar to regproc:
it's actually an OID, but it has the additional implication that it is
the OID
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > It's possible for a function to use a unique snapshot
> > if there are only SELECT statements in the function
> > but it's impossible if there are UPDATE/DELETE or
> > SELECT .. FOR UPDATE statements etc.
>
> You are confusing sn
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Could you live with it when we don't allow a name to start
> > with a dollar, but allow the dollar inside or at the end of
> > the name?
>
> We had *better* not allow an identifier to start with $ --- or have
> you forgot
Jan Wieck <[EMAIL PROTECTED]> writes:
> Could you live with it when we don't allow a name to start
> with a dollar, but allow the dollar inside or at the end of
> the name?
We had *better* not allow an identifier to start with $ --- or have
you forgotten about parameters?
I tend
Paul Ramsey <[EMAIL PROTECTED]> writes:
> However, if I have an RPM-based installation, I *will* have
> the server headers I need. Why do we discriminate against people who
> compile from the tarball?
We don't. We do, however, assume that they read the installation
instructions:
The standa
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Are we going to do the "official" testing-on-all-supported-platforms
> Not usually. We didn't change that much.
More to the point, I don't believe there were any changes that had any
significance for portability...
regards,
I would take a hard look at R's extension packaging system
(www.r-project.org). Its the best in the business. It consolidates all
aspects of creating packages, including configuring, building, run-time
linking, documentation and testing. It also allows non-root users to
install packages in
> Peter Eisentraut wrote:
> > Jan Wieck writes:
> >
> > > Could you live with it when we don't allow a name to start
> > > with a dollar, but allow the dollar inside or at the end of
> > > the name?
> >
> > At the end would also be a problem because of parsing conflicts with
> > o
Peter Eisentraut wrote:
> Jan Wieck writes:
>
> > Could you live with it when we don't allow a name to start
> > with a dollar, but allow the dollar inside or at the end of
> > the name?
>
> At the end would also be a problem because of parsing conflicts with
> operators. (E.g.,
Jan Wieck <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
> > We do currently use $1 for params, so allowing dollar in the middle
> > seems better. However, I need to see multiple people who need it before
> > I would say OK. If we go adding things because _one_ person wants it,
> > we will
Jan Wieck writes:
> Could you live with it when we don't allow a name to start
> with a dollar, but allow the dollar inside or at the end of
> the name?
At the end would also be a problem because of parsing conflicts with
operators. (E.g., foo$<$bar) I don't really like this i
> Bruce Momjian wrote:
> > We do currently use $1 for params, so allowing dollar in the middle
> > seems better. However, I need to see multiple people who need it before
> > I would say OK. If we go adding things because _one_ person wants it,
> > we will end up with a mess. Someone is working
Bruce Momjian wrote:
> We do currently use $1 for params, so allowing dollar in the middle
> seems better. However, I need to see multiple people who need it before
> I would say OK. If we go adding things because _one_ person wants it,
> we will end up with a mess. Someone is working on an
> O
hellow all
how can I store Binary values in a table of postgresql database?
thanks...
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
> > > In order to lower porting issues, I think it'd be nice to add
> > > that to PostgreSQL as well. It's two more characters in
> > > scan.l and doesn't break the regression test.
> > >
> > > Objections?
> >
> > Yes. We would move from standard C identifiers to $ identifie
Bruce Momjian wrote:
> > I'm not sure if it's according to or violating the standard.
> > But most other databases allow a '$' inside of identifiers.
> > Well, most of them recommend not to use it, but hey guy's,
> > what's a recommendation for a programmer?
> >
> > In or
So... will current 7.1.1 databases upgrade without problems to 7.1.3?
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through t
> I'm not sure if it's according to or violating the standard.
> But most other databases allow a '$' inside of identifiers.
> Well, most of them recommend not to use it, but hey guy's,
> what's a recommendation for a programmer?
>
> In order to lower porting issues, I t
Brook Milligan writes:
> Doesn't this discussion indicate that the time is fast approaching, if
> not already past, for some type of system for handling installation of
> 3rd party software?
Yes.
> - Definition and implementation of the interface to be provided for
> extensions. Presumably,
I'm not sure if it's according to or violating the standard.
But most other databases allow a '$' inside of identifiers.
Well, most of them recommend not to use it, but hey guy's,
what's a recommendation for a programmer?
In order to lower porting issues, I think it'd be
Peter Eisentraut wrote:
> The 7.1 RPMs should contain the server side headers somewhere. Earlier
> versions only included a not very well defined subset of them.
Indeed they do (nice!), which brings me to a different question:
1 - I download the tarball
2 - ./configure ; make ; make install
Tom Lane wrote:
>
> When someone sends me a Windoze implementation of the proposed
> SOCK_STRERROR() macro, I'll see about fixing it. Till then
> I can't do much.
>
> regards, tom lane
>
Could you please review the following patch for libpq.
I've implemented the SOCK
[EMAIL PROTECTED] (Tim Allen) writes:
: [...] Near the end he gets specifically asked about "Red Hat
: Database" as a competitive threat, and he responds that he doesn't
: think anyone can match their "investment" of "800 professionals" to
: work on SQL Server. [...]
It would be naive to dism
On Wed, Aug 15, 2001 at 05:16:42PM +0200, Peter Eisentraut wrote:
> Karel Zak writes:
>
> > before some time I was discuss with Tatsuo and Thomas about support
> > for synonyms of encoding names (for example allows to use
> > "ISO-8859-1" as the encoding name) and use binary search for searching
Paul Ramsey writes:
> - One of the things we have run up against is that for most linux
> distributions, the postgresql-devel package does not include postgres.h
> in the header package. This is not necessary for client-side programs,
> but it is for server-side extensions. So people cannot compi
> By the way,
>
> Are we going to do the "official" testing-on-all-supported-platforms
> before making this (hopefully final 7.1.x) release? It'd be embarrasing
> if it failed on something it's supposed to work on...
>
> If so, do we make use of Vince's Regression Test form?
> http://www.ca.pos
> Is it possible to include patch for libpgtcl & tcl >8.0
> in this release?
Much too risky. We don't know about compatibility with earlier tcl
versions.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is
Tatsuo Ishii writes:
> However, I think we should focus on more fundamental issues
> than those trivial ones. Recently Thomas gave an idea how to deal with
> the internationalization (I18N) of PostgreSQL: create character set
> etc.
I haven't actually seen any real implementation proposal yet.
Karel Zak writes:
> before some time I was discuss with Tatsuo and Thomas about support
> for synonyms of encoding names (for example allows to use
> "ISO-8859-1" as the encoding name) and use binary search for searching
> in encoding names.
Funny, I was thinking the same thing last night...
A
On Wed, Aug 15, 2001 at 11:28:35PM +0900, Tatsuo Ishii wrote:
> Thank you for your suggestions. I'm not totally against your
> suggestions (for example, I'm not against the idea that changing all
> current encoding names to more "standard" ones for 7.2 if it's your
> concern). However, I think we
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I have added new function called "convert" similar to SQL99's convert.
> > Convert converts encoding according to parameters. For example, if you
> > have a table named "unicode" in an Unicode database,
>
> > SELECT convert(text_field, 'LATIN1') FROM
Thank you for your suggestions. I'm not totally against your
suggestions (for example, I'm not against the idea that changing all
current encoding names to more "standard" ones for 7.2 if it's your
concern). However, I think we should focus on more fundamental issues
than those trivial ones. Recen
I was just looking at adding SERIAL4 and SERIAL8 pseudo-types to the
system, per our previous discussion, and I started to wonder why SERIAL
is treated as a keyword by the grammar. Wouldn't it be better to remove
that keyword and allow the grammar to parse "serial" as a type name?
Then analyze.c
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I have added new function called "convert" similar to SQL99's convert.
> Convert converts encoding according to parameters. For example, if you
> have a table named "unicode" in an Unicode database,
> SELECT convert(text_field, 'LATIN1') FROM unicode;
>
By the way,
Are we going to do the "official" testing-on-all-supported-platforms
before making this (hopefully final 7.1.x) release? It'd be embarrasing
if it failed on something it's supposed to work on...
If so, do we make use of Vince's Regression Test form?
http://www.ca.postgresql.org/~vev
Is it possible to include patch for libpgtcl & tcl >8.0
in this release?
Regards,
Mikhail Terekhov
Bruce Momjian wrote:
>
> > > > I have to fix my old fault in TID handling.
> > > > I am able to have a cvs access now and would
> > > > commit the fix to 7.1 branch.
> > >
> > > Hiroshi, are you d
None of my Solaris boxes have direct internet access, but if someone is
willing to make a snapshot tar.gz/tar.bz2 file, I can download and test
on Solaris 8 SPARC/INTEL.
:)
Regards and best wishes,
Justin Clift
Tatsuo Ishii wrote:
>
> > OK, 7.1.3 is packaged and ready to go, date stamped Augu
Probably it would be possible to implement ub-tree
using GiST interface.
Oleg
On Wed, 15 Aug 2001, Wald, Matthias wrote:
> Is there any intention to implement ub-trees?
> For more information visit the page of the
> Mistral project. There is information of how to
> integrate ub-trees in
Hi,
before some time I was discuss with Tatsuo and Thomas about support
for synonyms of encoding names (for example allows to use
"ISO-8859-1" as the encoding name) and use binary search for searching
in encoding names.
I mean that we can during this change a little clean up encoding
stuf
Is there any intention to implement ub-trees?
For more information visit the page of the
Mistral project. There is information of how to
integrate ub-trees in a db-kernel or extend the
b-tree implementation. ub-trees enhances very
much multi conditioned selects. The link is
http://mistral.in.tum.
Hi,
we finished first stage of our proposal for changing of index AM tables
(see for reference http://fts.postgresql.org/db/mw/msg.html?mid=1029290)
I attached 3 files:
1. patch_72_systbl.gz - patch to current CVS
2. btree_gist.tar.gz - contrib/btree_gist module -
imple
> OK, 7.1.3 is packaged and ready to go, date stamped Auguest 15. Can
> people with cvs 7.1 branches review it?
Compling/regression tests seems fine on my box (Linux kernel
2.2/egcs-2.91/glic 2.1.3). Documents are also compiled fine.
--
Tatsuo Ishii
---(end of broadcast)
> I have added new function called "convert" similar to SQL99's convert.
> Convert converts encoding according to parameters. For example, if you
> have a table named "unicode" in an Unicode database,
Forgot to mention that anyone who wants to try the new function should
do initdb. I did not incr
Gavin Sherry wrote:
> Seems like a fairly large amount of talk about stuff which should be
taken
> care of internally by corporations who have such interests.
Not entirely. As a freelancer, I've used OLAP (front-end only, ie pivot
tables in Excel) to help me produce invoices from my timesheet
I have added new function called "convert" similar to SQL99's convert.
Convert converts encoding according to parameters. For example, if you
have a table named "unicode" in an Unicode database,
SELECT convert(text_field, 'LATIN1') FROM unicode;
will return text in ISO-8859-1 representation. Thi
47 matches
Mail list logo
