> I wonder whether we shouldn't
use the most recent address we have for
> the git conversion, though.
> Thomas, do you have a preference? See
>
http://archives.postgresql.org/pgsql-hackers/2010-08/msg01078.php
for
> context.
I'd alrea
> The other day there was a discussion around the fact that X'' will
> get converted into an integer constant...
> ... while SQL99 says that this syntax *should* be used to specify a
> "binary string". It looks like the hex-to-integer magic actually occurs
> in the lexer, and then the integer
...
> Since I didn't see an immediate batch of squawks, I think I will go
> ahead and commit what I have; we can always revisit the implicit-allowed
> flag settings later.
Squawk. But I haven't had time to look at the full ramifications of your
proposed change, so it is inappropriate to comment,
...
> Also, the numeric regression tests takes much longer than the other
> tests. I don't see why a test of that length is required, compared to
> the other tests. Probably time to pair it back a little.
The numeric types are inherently slow. You might look at what effect you
can achieve by re
> Which ones are you concerned about? As of 7.2, the only ones that use
> numeric accumulators for non-numeric input types are
...
OK, I did imply that I've been wanting to ask this for some time. I
should have asked during the 7.1 era, when this was true for more cases.
:)
> All of these seem
...
> Jan, regression is not a test of the level a developer would use to make
> sure his code works. It is merely to make sure the install works on a
> limited number of cases. Having seen zero reports of any numeric
> failures since we installed it, and seeing it takes >10x times longer
> than
...
> It is my understanding that RPM does run that test. My main issue is
> why does numeric have to be so much larger than the other tests? I have
> not heard that explained.
afaict it is not larger. It *does* take more time, but the number of
tests is relatively small, or at least compatible
...
> I don't really consider this a bug; at least, fixing it would imply not
> const-simplifying the result expressions of CASEs, which is a cure far
> worse than the disease IMHO. Does anyone think we *should* allow CASE
> to defeat const-simplification?
No. Constant-folding during parsing sho
...
> OK, how about a NOTICE stating that the missing columns were filled in
> with defaults?
Yuck. There is a short path from that to rejecting the insert, but
printing the entire insert statement which would have been acceptable in
the error message ;)
- Thomas
> Is PostgreSQL broken? Or is it FreeBSD?
Both at most. FreeBSD at least ;)
The Posix definition for mktime() insists that the function return "-1"
if it has an error. Which also happens to correspond to 1 second earlier
than 1970-01-01, causing trouble for supporting *any* times before 1970.
P
> Would it make sense to flatten out INNER JOINs only when the total
> number of tables involved is less than some parameter N? N
> around six or eight would probably keep the complex-query crowd
> happy, while not causing unintuitive behavior for simple queries.
> Anybody who really likes the cu
...
> I'm of a belief that *eventually* we really can take enough of the
> variables into consideration for planning the best query every time. I
> didn't say it was gunna be soon, nor easy though.
I agree. But I'd like to eliminate the optimizer variability which
depends solely on the syntactic
...
> My one most important experience (I've had more than one) with this whole topic
> is DMN's music database, when PostgreSQL uses the index, the query executes in
> a fraction of a second. When "enable_seqscan=true" PostgreSQL refuses to use
> the index, and the query takes a about a minute. N
...
> Thanks a lot for the excellent software.
My personal view is that one might consider using the same BSD license
as PostgreSQL itself as a gesture of appreciation for the software you
are using. Contribute or not, it is your choice. But if you are
benefiting from the software (and lots of fo
I'm trying to (finally) get my rather extensive patches (mostly
addressing int8 versions of date/time storage) applied but am now having
trouble with the regression tests.
I'm sure this has been on the list, but I'm not recalling the
explanation or workaround. My guess is that it is related to co
> > The first symptom is failures in the char regression test...
> initdb --no-locale
Ooh. Thanks, that fixes it. Where would I have found this in the docs? I
was looking in the wrong place (in configure/build) rather than at
initdb. Should we have something in the release notes? I see (now that
I've applied patches to implement an int64-based data/time storage
scheme. I've also accumulated some other minor fixes, which result in an
initdb being required (sorry!).
Note that the *default* timestamp type is now TIMESTAMP WITHOUT TIME
ZONE. This is what we discussed previously for the trans
btw, I've updated the regression tests and results for my platform, but
other platforms (e.g. Solaris) will need their results files updated...
- Thomas
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http:/
> I'm seeing half a dozen gcc warnings as a result of these patches.
> Do you want to fix 'em, or shall I?
Where are they? I haven't noticed anything in the files I have changes;
are the warnings elsewhere?
- Thomas
---(end of broadcast)-
> > I'm seeing half a dozen gcc warnings as a result of these patches.
> Where are they?
More specifically, the *only* compiler warning I see (other than the
usual yacc/lex symbol warnings) is that a routine in gram.y,
set_name_needs_quotes(), is defined but not used. Don't know where that
routin
> With fairly vanilla configure options, I get...
Please be specific on the options and platform. I do *not* see these
warnings here with my "fairly vanilla configure options" ;)
Can't fix what I can't see, and we should track down what interactions
are happening to get these variables exposed..
> >> With fairly vanilla configure options, I get...
> > Please be specific on the options and platform.
> HPUX 10.20,
> ./configure --with-CXX --with-tcl --enable-cassert
Boy, how plain-vanilla. *My* configure line is all of
./configure --prefix=/home/thomas/local
But I do override some parame
> I think it was originally needed only for the CRC code, so we put it
> there to begin with. Clearly should be in a more widely used place now.
> Do you have any opinion whether c.h or int8.h is the Right Place?
> I'm still dithering about that.
In looking at the code, istm that the versions sh
> FWIW, I'm still seeing:
> gram.y:99: warning: `set_name_needs_quotes' declared `static' but never
> defined
Ack. Sloppy patching. Should be fixed now...
- Thomas
---(end of broadcast)---
TIP 2: you can get off all lists at once
> I agree that we don't want to reinstate that hack on the gram.y side.
> However, it seems to me way past time that we did what needs to be done
> with variable.c --- ie, get rid of it. All these special-cased
> variables should be folded into GUC.
Or in some cases into pg_database? We might wa
> > But I do override some parameters in my Makefile.custom:
> > CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING
> If you use -O0 then you miss most of the interesting warnings.
?? Not in this case. afaik -O0 suppresses most optimizations (and hence
does not reorder instructions, which is why I use it for
...
> Ah, but we *have* that ability right now; see Peter's recent changes
> to support per-database and per-user GUC settings. The functionality
> available for handling GUC-ified variables is now so far superior to
> plain SET that it's really foolish to consider having any parameters
> that ar
...
> In particular, you don't get "unused variable" and "variable may not
> have been set before being used" warnings at -O0, because the
> control-flow analysis needed to emit those warnings is not done at -O0.
Right. The point is that I don't get those (apparently) with -O2 either,
with my par
...
> regression=# set seed to 1,2;
> server closed the connection unexpectedly
> (crash is due to assert failure)
Now that I look, the assert is one I put in explicitly to catch multiple
arguments! I wasn't sure what the behavior *should* be, though I could
have done worse than simply checking f
Hmm. In looking at SET, why couldn't we develop this as an extendable
capability a la pg_proc? If PostgreSQL knew how to link up the set
keyword with a call to a subroutine, then we could go ahead and call
that routine generically, right? Do the proposals on the table call for
this kind of impleme
...
> If you're suggesting setting up an actual database table, I'm not
> sure I see the point. Any system parameter is going to have to be
> tied to backend code that knows what to do with the parameter, so
> it's not like you can expect to do anything useful purely by adding
> table entries. T
> Right. The point is that I don't get those (apparently) with -O2 either,
> with my particular compiler. Hmm. Actually, I *do* get those if I make
> sure that some of the other options are set too; my quick test added -O2
> but left out some of the -w switches. OK, never mind...
btw, now that I'
> On FreeBSD/Alpha, current CVS:
...
> ../../../../src/include/utils/int8.h:35: warning: `INT64CONST' redefined
> ../../../../src/include/utils/pg_crc.h:85: warning: this is the location of
> the previous definition
afaict this is OK (that is, the compiled code should work) until we get
the defin
I've committed a bit more to variable.c to handle integer inputs to GUC
parameters (string and float were already supported). I've included the
cvs log message below.
Further changes aren't precluded of course, but the code now supports
string, integer, and floating point inputs to parameters (fo
I'd like to implement *something* to help us collect information on what
platforms actually have what features. This would be useful, for
example, for figuring out whether any platforms are lacking 8 byte
integers or are missing timezone infrastructure.
I was thinking about something like "make r
> If you want to collect information about what features are portable you
> can check other software packages, product manuals, ports trees, etc.
> Most issues are documented someplace.
Oh goodness. Thanks for offering me a new hobby ;)
> Btw., yes, 8 byte integers are missing on some platforms.
> OK, would people please vote on how to handle SET in an aborted
> transaction?
> at the end, should 'x' equal:
> 1 - All SETs are rolled back in aborted transaction
> 2 - SETs are ignored after transaction abort
> 3 - All SETs are honored in aborted transaction
>
I've posted Mandrake RPMs for PostgreSQL 7.2.1 at
ftp://ftp.postgresql.org/pub/binary/v7.2.1/RPMS/mandrake-8.1
Thanks to Lamar Owens for the source RPM; I didn't have to change a
thing to get these built for Mandrake!
- Thomas
---(end of broadcast)
> I've been thinking this over and over, and it seems to me, that the way
> SETS in transactions SHOULD work is that they are all rolled back, period,
> whether the transaction successfully completes OR NOT.
Very interesting! This is a *consistant* use of SET which allows
transactions to be const
...
> This would make it impossible for SET to have any persistent effect
> at all. (Every SQL command is inside a transaction --- an
> implicitly-established one if necesary, but there is one.)
Of course the behavior would need to be defined from the user's
viewpoint, not from a literal descrip
...
> Agreed, very non-intuitive. And can you imagine how many applications
> we would break.
What is non-intuitive about it? What it *does* do is free the programmer
from worrying about side effects which *do* break applications.
Rather than dismissing this out of hand, try to look at what it
> It's hardly a trivial point, seeing that transactions are such a
> fundamental aspect of the system. The statements that we have now that
> depend on being-in-a-transaction-block-or-not (eg, VACUUM) are ugly
> kluges IMHO.
This is certainly not in the same category. And I'm sure you can see
up
> My problem was that on my 7.1.3 db, I have timestamp columns with
> fonctinal indices as date(column).
> Thes indices (indexes) wont work anymore because they're not marked loosy.
> I've been told that I should go for timestamp without timezone instead,
> witch is okay because all timezones are
> I don't really get it. We had a voting and I think I saw a
> clear enough result with #1, transactional behaviour, as the
> winner.Maybe I missed something, but what's this
> disscussion about?
Getting the right solution ;)
There was not a consensus, just a vote, and the *reas
...
> Now, I do not wish to have a manifesto, but a short and sweet "this is who we
> are, and this is what we do" could be a positive thing.
"PostgreSQL is the most advanced open-source database available
anywhere"
has appeared in the docs for quite some time, and has appeared in other
mention
...
> That is, '60' is read as so many hours, '1.5' is read as so many
> seconds. This seems a tad inconsistent.
They fulfill two separate use cases. Time zones can now be specified as
intervals, and the default unit must be hours. A number with a decimal
point is usually in units of seconds, an
(redirected to -hackers)
> > * Is there anything open about the DLM spec or code? I.e., could it
> > actually be used in a project like PostgreSQL?
The code is not open (despite the OpenDLM name :/
> > * Is there any open source equivalent?
http://oss.software.ibm.com/dlm/
> > * Have you loo
> Is there any rhyme or reason to these ISO format date parsing rules?
Yes. Though adjustments to the rules are possible, so things are not set
in concrete. There *should* be a complete description of the date/time
parsing rules in the User's Guide appendix.
> Why can't someone store the year wi
...
> (1) Major version upgrade. This is a hard one, having to dump out and restore a
> database to go from 7.1 to 7.2 or 7.2 to 7.3 is really a hard sell.
Hmm, maybe it would be more acceptable if we charged $40k per license,
but refunded $40k if you *want* to dump/reload. Gets that motivation
l
> I'd like to contribute new code for Postgres geometry type 'path' operations
> (including line buffer). Where should I send this?
Send to [EMAIL PROTECTED] It may be helpful to (i.e. please
do) post a summary of what you are intending to send to this mailing
list so folks have an idea of what i
...
> While it would be nice to have one pgaccess that can work with any pgsql
> backend, that's not currently the case. One solution would be to work
> on the release branch, but that's discouraged - bug fixes only.
Actually, CVS can support this just fine (I'll mention how below) but
afaict the
...
> If nobody feels like managing this - let's give it a little bit of life and
> move it a bit forwards - and then talk again.
Iavor, I meant to be helpful; I was trying to put a name on The New
Group of Enthusiastic Developers Who Are Interested In Advancing
Pgaccess and shortened it to "Iavo
> I was expecting it to round off ... I think there's something wrong with
> the arithmetic in AdjustIntervalForTypmod.
Yup. I've now updated the lookup tables used for the calculation for the
--disable-integer-datetimes case. The --enable-integer-datetimes case
was already calculated correctly.
> With CVS tip (and float-type timestamps) I get
...
> Seems to be the same result no matter what timestamp is put in.
Yup. Broken for double timestamps. Will patch...
- Thomas
---(end of broadcast)---
TIP 6: Have you searched our
...
> Our implementation is broken, then. Thomas, is this fixable for a 7.2.x
> release, or something for 7.3?
"Our implementation is broken, then" is really not a conclusion to be
reached. The de facto behavior of mktime() on all world-class
implementations is to support pre-1970 times. This ha
> > They are just wanting to be standard. I know this; I just can't say how I
> > know this. But the link to the ISO definition is
> > http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14
...
> FWIW, here's what I see in the C99 spec pdf for mktime and the tm
> struct
...
> But, in any case, I didn't mean to step on your toes by any of my comments; I
> completely agree with you that glibc and the ISO C standard cited are daft in
> this.
No complaints from my toes; I was just ventilating about stupid
breakage.
- Thomas
---
> Proposal #1: TIMESTAMP WITHOUT TIME ZONE as default
Hmm. Already done for 7.3 :)
7.2 introduced that data type, and 7.1 did not have it, so we had one
release cycle to allow dump/restore to do the right thing.
> Proposal #2: We need more time zones.
The other complaint is that we have too m
> > SuSE already does this. I wonder how they've handled this issue with
> > 8.0?
> Their glibc doesn't have that problem.
My strong recollection is that a SuSE guy was the one applying the
change. So this is coming to those systems too. I may not remember that
correctly though...
> Personally,
> Why not fix it completely with this stuff:
> ftp://elsie.nci.nih.gov/pub/
> Just an idea.
Ah, the real zic implementation. afaik this is public domain or BSD or
at least compatible with our BSD license wrt distribution.
Great idea. We may end up doing this! Though I hate for the project to
pic
> IIRC the spec is not _really_ broken - it still allows the correct
> behaviour :)
Yes.
> The fact the ISO spec is broken usually means that at least one of the
> big vendors involved in ISO spec creation must have had a broken
> implementation at that time.
Right. IBM.
> Most likely they hav
...
> > AIX and (I think) Irix.
> How do we currently support AIX/Irix ?
Dates and times prior to 1970 have no time zone (they are in GMT, as is
the case for all platforms on dates before 1903 and after 2038). We have
separate regression test results for those platforms.
> There are certain oddities in current interval behaviour:
> template1=# select '125.567772 seconds'::interval(12);
> ERROR: INTERVAL(12) precision must be between 0 and 6
> The documentation says 0 and 13 (users' manual 3.5.1.6).
OK, docs need fixing.
> Then there seem to be some
> > OK. They must be new guys.
> :-) Very funny.
Hey, it worked. Got you out of the woodwork. :))
- Thomas
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourE
> > This is due to floating point rounding issues on output. Try configuring
> > and compiling with --enable-integer-datetimes and you should see this go
> > away.
> Hey, where is this compile-time option documented? It may have part of the
> functionality I need.
./configure --help
Isn't anywh
> > ./configure --help
> > Isn't anywhere else yet.
> Not seeing it. Is this a 7.3 thing? What does it do?
Sorry, yes it is a 7.3 thing.
- Thomas
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PR
...
> Why should we rely on broken glibc and the standard? Why don't we make
> our own mktime() and use it on all platforms.
The downside to doing that is that we then take over maintenance of the
code and, more importantly, the timezone database.
But it might be the best thing to do. It looks l
...
> But anybody using Unix dates as "general dates" has leaped into exactly the
> same sort of trap that caused people to get so paranoid about Y2K.
Certainly true. We don't use Unix dates as "general dates", we use the
Unix time zone database and API for dates and times within the year
range o
...
> Well, this does sound a bit more involved than I was envisioning. There
> are a few items wrt SRFs that I should finish first, but I'll come back
> to this afterward if no one else does first.
The first cut might be to reproduce the functionality we already have.
That would allow us to (opt
> > The last phase could be extending the API to allow multiple simultaneous
> > time zones, detection of bad time zones, etc etc. This would involve API
> > changes or extensions, and breaks compatibility with system-supplied
> > infrastructure.
> One thing that wasn't clear to me, but could use
> > > > ./configure --help
> > > > Isn't anywhere else yet.
> > > Not seeing it. Is this a 7.3 thing? What does it do?
> > Sorry, yes it is a 7.3 thing.
> What does --enable-interval-integers do? I don't want to bother writing up
> issues you've already taken care of.
Not implemented afaik. Or
...
> rserver only does single-master, while most people want multi-master.
As you probably know, rserv is not limited to only a single instance of
a single master. Many replication problems can be described as a "single
source" problem (or should be described as such; moving to a fully
distribut
> >> 2. Add _P to the following lex/yacc tokens to avoid collisions
> >> CONST, CHAR, DELETE, FLOAT, GROUP, IN, OUT
> I'm tempted to suggest that we should stick _P on *all* the lexer token
> symbols, rather than having an inconsistent set of names where some of
> them have _P and some do not. O
> > "P" for "Parser".
> Oh, okay. I'm not intent on changing it, just was wondering what the
> motivation was. What do you think of changing all the token symbols to
> be FOO_P? (Or P_FOO, per your comment, but I'd just as soon leave alone
> the ones that already have a suffix.)
No problem her
...
> Good summary. I think we would support both threaded and fork()
> operation, and users can control which they prefer. For a web backend
> where many sessions are a single query, people may want to give up the
> stability of fork() and go with threads, even on Unix.
I would think that we w
...
> Notion:
> Have one version do both. Your server can fork(), and your sever can
> thread. It can fork() and thread, it can fork() or thread.
> That gives the best of all worlds. One client who has his attachments
> to a database all setup might want to do a bunch of similar queries.
> Henc
Tony Griffiths wrote:
>
> Hi,
> I'm trying to start to program with the PostgreSQL's geometric primitive
> types, and have started to write some code using them (PostgreSQL
> version 7.1.3, installed from source). However when I
> include the file utils/geo_decls.h I get an error starting that th
> Please give me feedback on this...
> There are a few problems currently with the Interval data type. The biggest
> is that the current rules give us no clear path for implementation of a full
> set of operators. The SQL92 standard is no help here; its implementation is
> unintuitive and extrem
I've just committed changes which implement three SQL99 functions and
operators. OVERLAY() allows substituting a string into another string,
SIMILAR TO is an operator for pattern matching, and a new variant of
SUBSTRING() accepts a pattern to match.
Regression tests have been augmented and pass.
OK, I *really* need to get my majordomo account fixed up to keep from
stalling posts from my various accounts to the various lists.
I think that I can enter some aliases etc to allow this; where do I find
out how? Searching the -hackers archives brought no joy since the
obvious keywords show up
I've just committed changes which implement three SQL99 functions and
operators. OVERLAY() allows substituting a string into another string,
SIMILAR TO is an operator for pattern matching, and a new variant of
SUBSTRING() accepts a pattern to match.
Regression tests have been augmented and pass.
> > fduch=> SELECT to_char('100days'::interval, '-MM-DD HH24:MI:SS');
> > -
> > -00-10 00:00:00
> I already said it. The to_char() is 'tm' struct interpreter and use
> standard internal PG routines for interval to 'tm' conversion. We can
> talk about why 100days is
> > I already said it. The to_char() is 'tm' struct interpreter and use
> > standard internal PG routines for interval to 'tm' conversion.
> The point is it should _not_ do that for interval.
I use the tm structure to hold this structured information. I *think*
that Karel's usage is just what i
> Also, you neglected to add PLACING to the gram.y keyword category lists.
OK. I'm also tracking down what seems to be funny business in the regex
pattern caching logic, so will have a couple of things to fix sometime
soon.
- Thomas
---(end of broadcast)
> TODO item marked as done:
> * -Add SIMILAR TO to allow character classes, 'pg_[a-c]%'
Darn. Will have to be more careful next time ;)
- Thomas
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
> > How is SIMILAR TO different from ~ ?
> >From the part of Thomas's email you snipped:
>Implement SQL99 SIMILAR TO as a synonym for our existing operator "~".
> So the answer is "not at all"
Right. I'm not certain about the regex syntax defined by SQL99; I used
the syntax that we already ha
Good points; not sure why I didn't pick up on this too.
I should point out that I've seen code with heavy Oracle-isms brought
into PostgreSQL using ecpg with amazingly few changes. It is a great
piece of code; any large complaints should perhaps be directed at the
SQL standards themselves...
...
> I would assume that they would use their brain.
Way uncalled for. You must have some other underlying issues to get this
bad 'tude, but please note that ad hominum attacks are *never* welcome
on this or any other PostgreSQL mailing list.
Regards.
- Thomas
-
Thanks for the info! I have a question...
> As usual: ( ) + * [ ] |
> Instead of dot . there is underscore _
> There is % to mean .* just like LIKE
> There is no ? or ^ or $
> Regular expressions match the whole string, as if there were an
> implicit ^ before and $ after the pattern. You ha
> Also, you neglected to add PLACING to the gram.y keyword category lists.
I just now added and committed it as a reserved word.
- Thomas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresq
As you probably know, SQL99 has dropped the rather useless
categorizations of "basic", "intermediate", and "advanced" SQL
compliance and instead lists a large number of labeled features. I've
put these into an appendix for the docs (not yet committed to cvs).
The list is organized as a (for now)
I've just committed changes to include an SQL99 feature list as an
appendix in the User's Guide. While preparing that I noticed a feature
or two which would be trivial to implement, so we now have LOCALTIME and
LOCALTIMESTAMP function calls per spec (afaict; the spec is very vague
on the behaviors
> You wrote "was either to voluminous" instead of "was either too voluminous"
> in the first paragraph of the appendix...
Thanks!
- Thomas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgre
> I received this via private email. Do we want CORRESPONDING added to
> the TODO list?
Sure. Though since we now have features.sgml which has the complete set
of SQL99 itemized features we perhaps should shrink the ToDo entries
regarding SQL99 features to only one:
"Support additional SQL99 fe
I've just updated features.sgml to have a list of supported features
followed by a list of unsupported ones. There are some items in the
"unsupported list" which look easy to do. I've got patches for a "MATCH
SIMPLE" clause on referential integrity declarations, and am developing
patches for CREAT
I've got patches for the CREATE CAST/DROP CAST feature (just a
rearrangement of our existing function declaration syntax). The SQL99
form assumes that an existing function will be used for the cast
definition, so I've extended the syntax to allow that and to have an
alternate form which has more o
...
> MySQL has such a team, and so does Oracle, and it helps. Linux was in a
> similar boat, with multiple companies behind Linux, and every one
> promoting its own company rather than Linux itself. We need large
> PostgreSQL companies that promote themselves, and PostgreSQL along with
> it. L
> > a) The client-side programmer has to be responsible for parsing the
> > returned string, which could cause problems if the output format of the
> > ADT is changed, and
> You seem to be proposing that we instead expose the internal storage
> format of the ADT, which seems to me to be much more
> Ah, I see --- more or less make all of utils/adt/ available to be
> linked into clients.
> > That is a Good Idea in principle. In practice, ...
> Yeah, it'd be a huge amount of work. For starters, all that code
> relies on the backend environment for error handling and memory
> management...
I
> > I've got patches for the CREATE CAST/DROP CAST feature (just a
> > rearrangement of our existing function declaration syntax). The SQL99
> > form assumes that an existing function will be used for the cast
> > definition, so I've extended the syntax to allow that and to have an
> > alternate f
1 - 100 of 639 matches
Mail list logo
